JVMTI OOM handling when arrays / objects are too large

[Jeremy Manson]

I'm not sure if the heap dump is as interesting as the fact that you
are going to take some action when you do OnOutOfMemoryError.  It is
rather surprising to have specified that a particular action is taken
when a OOME occurs, and have it not happen when an OOME occurs.

I guess that because it is a limitation in the VM, you could throw
VirtualMachineError instead.

Jeremy

On Mon, Jun 15, 2009 at 2:37 AM, 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.
>