Heap OOM for no apparent reason?

[Raman Gupta]

On 06/03/2011 03:28 AM, John Coomes wrote:
> Y. Srinivas Ramakrishna (y.s.ramakrishna at oracle.com) wrote:
>> Sorry, sent previous email without addressing all of the issues.
>>
>> On 6/2/2011 6:15 PM, Raman Gupta wrote:
>>> It would be *really* handy if there were a switch like:
>>>
>>> -XX:+StackTraceOnOutOfMemoryError
>>
>> Yes that would be handy, and probably not too difficult.
>> But I wonder also if something like OnOutOfMemoryError or
>> like would already get you enough info to get close to
>> the problem ... (although may be because it's executed in
>> a separate shell, by the time the command executes the
>> process has likely gone well past the point when the problem
>> occurred).
> 
> No need to worry, the OnOutOfMemoryError commands are run while the
> JVM is at a safepoint.  This worked for me:
> 
>   java -XX:OnOutOfMemoryError='jstack %p' ...
> 
> -John

Excellent -- will try this later today.

I did a quick search for places where OOME is caught and swallowed and
found a few places within the JDK (such as direct ByteBuffer
allocation), as well as a couple places in other libraries such as
commons-pool and jgroups, the latter of which is used by Infinispan
(though in some cases, but not all, those are logged before being
swallowed). In short though, I still don't definitively know where the
problem allocation is. So running jstack via OnOutOfMemoryError sounds
like it is just the ticket.

Cheers,
Raman