RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread
david.holmes at oracle.com
Fri May 24 04:30:34 UTC 2013
Are we still waiting for a second core-libs reviewer on this?
On 17/05/2013 5:56 PM, Thomas Schatzl wrote:
> On Fri, 2013-05-17 at 10:47 +1000, David Holmes wrote:
>> On 16/05/2013 8:44 PM, Thomas Schatzl wrote:
>>> On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote:
>>>> I updated the test program and the patch in java.lang.ref.Reference
>>>> As for the problem of reproducibility, in my tests I had a 100%
>>>> reproduction rate with the previous version of the test.
>>>> However, now I also set -XX:-UseTLAB and -Xmx16M in the test program as
>>>> suggested in some other emails.
>>>> I will report back with a new webrev after some testing on more
>>>> platforms as suggested by David.
>>> a new webrev for the patch is at
>> I think the comment is somewhat confusing, but then the details here are
>> quite confusing. I guess the key part of this is that if OOME is thrown
>> we don't want to try and load InterruptedException - though I'm unclear,
>> based on normal exception processing semantics, when that might occur.
> I tried to clarify the comment a little; I also added a dummy
> instantiation of InterruptedException at the start of the test program
> to avoid OOME during class loading in this case as suggested by the
> other email.
> The new webrev is at
> I only compiled and tested this webrev that nothing broke locally, as
> the changes are minimal and mostly concerning comments. Pushing a jdk
> through jprt also takes a long time.
> Before sending you a patchset after it has been reviewed, I will push it
> through jprt again.
>> You can count me as a Reviewer and sponsor. I think only a second JDK/TL
>> Reviewer is needed here as no impact on hotspot.
More information about the core-libs-dev