JVMTI OOM handling when arrays / objects are too large

[Y. Srinivas Ramakrishna]

I am not a language spec expert, so this opinion is offered merely as
more grist for the on-going discussion mill...

Jeremy Manson wrote:
> 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.
>   

I agree with Jeremy and others in that the inconsistency in treatment of 
OOM is not particularly pleasant.
"Something like a VirtualMachineError" would be fine, except in as much 
as a literal reading
of the description of VirtualMachineError from the docs makes it sound 
somewhat
inappropriate for the current purpose:-

> Thrown to indicate that the Java Virtual Machine is broken or has run 
> out of resources necessary for it to continue operating. 
Can a VirtualMachineError be caught and ignored? (The implied inability 
to continue operating sounds
particularly ominous ;-)

In fact, OutOfMemoryError (OOME) seems to me to be entirely appropriate 
since we have been
asked to allocate an object that we happen to be unable to (whether 
that's because all
available memory is exhausted or that we never had that much memory 
available because
of physical or other limitations of the JVM is, I think, somewhat 
orthogonal, and is
detail that is anyway available in the detail string).

Anyway, I'd personally vote (even though I do not have a vote in this 
matter either,
coming as i do from the GC team)  for accepting the patch submitted, 
keeping the OOME, and
bringing it in line with other OOME in terms of respecting the 
OnOutOfMemory hook.
(I agree with Alan and others that dumping the heap is irrelevant and 
might be avoided,
but if that's what it takes for consistency, I am guessing that's fine too.)

PS: Note that this does not constitute a review of the code, but rather 
a voice in favour
of the approach taken in the submitted patch.

my $0.02.
-- ramki
> 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.
>>>       
>>