JVMTI OOM handling when arrays / objects are too large
martinrb at google.com
Sun Jun 14 12:37:29 PDT 2009
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:
Now has more tests and filled-in @bug line.
Hotspot fix webrev is at:
I've hacked on my private copy of webrev to make the output more suitable
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.
On Sat, Jun 13, 2009 at 10:18, Tim Bell <Tim.Bell at sun.com> wrote:
> Martin Buchholz wrote:
>> I've called my own bluff and implemented a test case for this
>> Jeremy's original fix is in this hotspot webrev:
>> 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
> For the test case:
>> 6850958 java/classes_lang JVMTI OOM handling when arrays / objects are too
> 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:
> 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:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev