|
Stack Overflow Error
Part:
1
2
(Continued from previous part...)
RecursiveCrash1:
HotSpot Client:
Stack overflow error at: 6740
HotSpot Server:
Stack overflow error at: 6113
JRockit: The execution hanged. System Task Manager showed 99% CPU usage and 9644K
memory usage. Ctrl-C did not end the process. I had to use the Task Manager to
end it.
JRockit with Management Server: Same result as the JRockit without Management
Server.
RecursiveCrash2:
HotSpot Client:
Stack overflow error at: 11233
HotSpot Server:
Stack overflow error at: 6792
JRockit:
Stack overflow error at: 62178
JRockit with Management Server:
Stack overflow error at: 62178
java.lang.IllegalMonitorStateException
The results were very interesting:
- JRockit was not able to report the line number of the source code where
the exception occurred.
- With the nested try statements included at each level of the recursive
call stack, JRockit was not able to terminate the execution.
- Without the nested try statements, HotSpot Clien was able to perform
about 4400 more recursive calls. But HotSpot Server showed no significant
difference.
- Without the nested try statements, JRockit not only behaved correctly,
but also out performed the HotSpot by 50000 more recursive calls. My guess
is that JRockit was not putting source code tracking information into the stack,
therefore was able to have a much larger stack. Can any one confirm this?
Comparison - JDK 1.6.0 vs. 1.4.0
After installing JDK 6u2, I tested all 3 stack overflow programs. Here are the results.
RecursiveCrash:
HotSpot Client:
at RecursiveCrash.sub(RecursiveCrash.java:10)
(repeated many times)
HotSpot Server:
at RecursiveCrash.sub(RecursiveCrash.java:10)
(repeated many times)
RecursiveCrash1:
HotSpot Client:
Stack overflow error at: 7673
HotSpot Server:
Stack overflow error at: 6870
RecursiveCrash2:
HotSpot Client:
Stack overflow error at: 10589
HotSpot Server:
Stack overflow error at: 7557
Part:
1
2
| 