JVMTI OOM handling when arrays / objects are too large

Tim Bell Tim.Bell at Sun.COM
Sun Jun 7 12:31:32 PDT 2009


Hi Jeremy
> Martin Buchholz tells me that three things have to happen to get a patch in:

Hi Martin :-)

> 1) Someone inside Sun has to file a bug.  Usually, this seems to be in
> the other bug database, but I guess it doesn't matter?

We hope to get a bridge working between the external bugzilla system
(good!) and the internal, proprietary bug tracking system (bad!).
Hopefully after we all recover from JavaOne week.

> 2) Two OpenJDK members have to review it (in practice).

One reviewer is required until the late stages of a release, then
two reviewers.  Of course, more reviewers are always better.

> Is my understanding correct?

What are the chances of getting a jtreg test case for this issue?

Tests that attempt to exhaust the heap are usually problematical,
but it would be worth a try.  Nice to have if we can get a test.

Tim


> Jeremy
> 
> On Fri, Jun 5, 2009 at 4:31 PM, Tim Bell <Tim.Bell at sun.com> wrote:
>> Hi Jeremy
>>> I was talking to some of the HS team at JavaOne, and they encouraged
>>> me to send some of the patches that we are working on at Google back
>>> to Sun.  (Everyone at Google is covered under a blanket SCA, so we can
>>> contribute back anything done by any Googler).
>>>
>>> To get started and test the waters, and because I have never tried to
>>> contribute to OpenJDK before, I thought I would send on a
>>> nearly-trivial fix that I made last year in response to a user
>>> complaint.  The issue was that when the user specifies
>>> -XX:OnOutOfMemoryError, and the OOM is thrown because a single memory
>>> allocation was too close to Integer.MAX_VALUE, the OnOutOfMemoryError
>>> command would not be executed.  I've attached the patch.  Let me know
>>> what I should do to proceed.
>> I created a bugzilla report for this issue:
>>
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100067
>>
>> That way we won't lose it in a pile of email.
>>
>> Tim
>>




More information about the hotspot-runtime-dev mailing list