JVMTI OOM handling when arrays / objects are too large
Alan Bateman
Alan.Bateman at Sun.COM
Mon Jun 15 02:37:07 PDT 2009
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.
More information about the hotspot-runtime-dev
mailing list