JVMTI OOM handling when arrays / objects are too large

[David Holmes - Sun Microsystems]

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

Martin Buchholz said the following on 06/15/09 05:37:
> I've polished the changes in preparation for committing.
> I'll commit once I have reviewer approval.
> You'll need to let me know which forest to commit to.
> 
> Test webrev is now at:
> http://cr.openjdk.java.net/~martin/jvmti-oom-test/
> 
> Now has more tests and filled-in @bug line.
> 
> Hotspot fix webrev is at:
> http://cr.openjdk.java.net/~martin/jvmti-oom/
> 
> I've hacked on my private copy of webrev to make the output more 
> suitable for
> external contributors.
> 
> I think it's time to again beg the hotspot integrators
> to be sure to run the java/lang and java/util/concurrent tests
> from the jdk repo before committing changes to MASTER.
> 
> Martin
> 
> On Sat, Jun 13, 2009 at 10:18, Tim Bell <Tim.Bell at sun.com 
> <mailto:Tim.Bell at sun.com>> wrote:
> 
>     Martin Buchholz wrote:
> 
>         I've called my own bluff and implemented a test case for this
>         http://cr.openjdk.java.net/~martin/jvmti-oom/
>         <http://cr.openjdk.java.net/%7Emartin/jvmti-oom/>
> 
>         Jeremy's original fix is in this hotspot webrev:
>         http://cr.openjdk.java.net/~martin/jvmti-oom-hotspot/
>         <http://cr.openjdk.java.net/%7Emartin/jvmti-oom-hotspot/>
> 
>         Sun folks (Tim?), please take up the process issues:
>         - please review test and fix
>         - file one (or two?) "real" bugs or
> 
> 
>     For the HotSpot VM side:
> 
>         6850957 hotspot/jvmti JVMTI OOM handling when arrays / objects
>         are too large
> 
> 
>     For the test case:
> 
>         6850958 java/classes_lang JVMTI OOM handling when arrays /
>         objects are too large
> 
> 
> 
> 
>         It's non-traditional to have fixes cross the hotspot/jdk barrier,
>         but this was the easiest way to write a test case.
> 
> 
>     This happens most often in the Serviceability area, for example when
>     fixes hit JVM TI and JDWP code.  You have another good example, where
>     the most natural test case fits in JDK/test/java/lang/ProcessBuilder
> 
>     The parent bugzilla report is:
> 
> 
>      https://bugs.openjdk.java.net/show_bug.cgi?id=100067
> 
>     I filed two internal bug reports that should be visible on
>     bugs.sun.com <http://bugs.sun.com>
>     in a few working days.  Using URL surgery, I predict the URLs will be:
> 
>      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850957
>      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850958
> 
>     Later today I will set up a forest, apply the patches from the
>     webrevs, and send it through JPRT.  I want to see the HotSpot
>     test results, as well as the new ProcessBuilder/Basic.java
> 
>     Tim
> 
>