JVMTI OOM handling when arrays / objects are too large

[Martin Buchholz]

The resolution of this is still uncertain.
We have one approval I think,
but all of the maintainers have expressed reluctance at making this change.
I continue to agree with Jeremy and be in favor of making this change,
but it's no big deal either way.
Perhaps Alan's opinion is authoritative, since he was the author.
Alan, perhaps you should give us an actual VETO, and we will shut up.

Martin

On Mon, Jun 15, 2009 at 02:37, Alan Bateman <Alan.Bateman at sun.com> wrote:

> David Holmes - Sun Microsystems wrote:
>
>> Martin, Jeremy,
>>
>> This change has been bugging me. I guess what I don't like is not the
>> "fix" but the fact that we report OutOfMemoryError for this situation in the
>> first place! We are not out-of-memory! We've been asked to allocate
>> something that is impossible to allocate given the physical constraints of
>> the memory system. The heap could actually be nearly empty! If I were
>> executing a OOM handler using the "onError" mechanism I'm not sure I'd want
>> it to run for this case.
>>
>> This fix makes this usage consistent with all the other OOM situations,
>> but we post JVMTI resource exhausted events when the resource need not be
>> exhausted at all! I'm not sure that is the right thing to do. Even assuming
>> it is the right thing to do, this may impact some tests as it now generates
>> additional JVMTI events.
>>
>> David Holmes
>>
> I'm glad you brought this up. I added the heap dump and also this
> (undocumented) OnOutOfMemoryError option some time ago. My memory on this is
> hazy but I think we decided to deliberately not to generate a heap dump or
> run the data collection actions for this case because it's not really
> resource related. The JVM TI event came later. I agree it is bit
> inconsistent but the exception message for this case ("Requested array size
> exceeds VM limit") does help to identity the problem.  The exception message
> and stack trace is lot more useful than a heap dump for this case.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090616/bf47c009/attachment.html