Martin Buchholz wrote:
I've called my own bluff and implemented a test case for this
http://cr.openjdk.java.net/~martin/jvmti-oom/
Jeremy's original fix is in this hotspot webrev:
http://cr.openjdk.java.net/~martin/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
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
