JVMTI OOM handling when arrays / objects are too large

[Jeremy Manson]

Not that I actually have a vote, but if Alan feels it is not worth
making, I would go back to arguing for something like a
VirtualMachineError to be thrown, because the behavior is out of spec.
 The current behavior - a sort-of-but-not-really OOME - is a little
odd.

Jeremy

On Tue, Jun 16, 2009 at 1:57 PM, Martin Buchholz<martinrb at google.com> wrote:
> 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.
>
>