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<[email protected]> 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 <[email protected]> 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.
