A DESCRIPTION OF THE REQUEST :
We have seen  the Out of Memory error using the hot spot JVM.  When this error is detected, only the "Out of Memory" message is print out. Here are the recommended action:

1. When "Out of Memory" is detected, in addition to print out "Out of Memory", please print out the entire stack.  If there is an application issue exists, the stack will help us track the problem down.

2. The "Out of Memory" is triggered in our environment by a memory intensive operation, when this error is encountered, the memory associated with this operation was not collected.  This results in all other less memory intensive operations to fail as well.


JUSTIFICATION :
This "Out of Memory" handling can help application team to identify where the cause of the problem is and to only punish the operation that requires a lot of memory when the free memory is low.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1. When "Out of Memory" occurs, the stack for the failed allocation is printed.

2. When "Out of Memory" occurs, the memory allocated by the entire thread is clean up.
ACTUAL -
1. When "Out of Memory" occurs, only "Out of Memory" is printed

2. When "Out of Memory" occurs, there are no actions to try to restore the JVM back to health.

---------- BEGIN SOURCE ----------
Any allocation program will do. Not application specific.
---------- END SOURCE ----------
(Incident Review ID: 229864) 
======================================================================

N/A

WIll look into this post tiger.

It's a known issue that JVM OOM error message does not contain enough
information to help debug the problem. One idea being proposed before is
to use fatal error handler to report OOM error. Also useful is to tell
user what caused the OOM, no space in C heap, no available file descriptor,
or too many processes/threads?

Also the second request is hard to implement within JVM. JVM is not kernel 
and threads are not processes. There is no way to safely kill an 
offending thread.

  xxxxx@xxxxx   2003-12-10


  xxxxx@xxxxx   2005-04-29 19:42:33 GMT