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<[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. > >
