RFR 8180627: gc/gctests/Steal/steal001: guarantee(cp->cache() == NULL) failed
harold seigel
harold.seigel at oracle.com
Wed Aug 2 11:49:10 UTC 2017
Hi Coleen, George,
Thanks for the reviews!
Harold
On 8/1/2017 5:57 PM, coleen.phillimore at oracle.com wrote:
>
> It looks good to me.
> Thanks!
> Coleen
>
> On 8/1/17 10:36 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this JDK-10 fix for JDK-8180627. Test
>> gctests/Steal/steal001 was occasionally failing when an
>> OutOfMemoryError exception happened to get thrown while linking a
>> class. The exception caused the class's linking to fail, but the JVM
>> did not properly clean up the constant pool cache of the partially
>> linked class. This caused the verifier to assert when the test tried
>> again to link the class because the verifier did not expect the
>> unlinked class to have an existing constant pool cache.
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8180627/webrev/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8180627
>>
>> The fix was tested with the JCK Lang and VM tests, the JTreg hotspot,
>> java/io, java/lang, java/util and other tests, the co-located NSK
>> tests, RBT tier2 - tier5 tests, and with JPRT.
>>
>> Additionally, the fix was tested by temporarily throwing an
>> OutOfMemoryError exception in
>> ConstantPool::initialize_resolved_references() and then checking that
>> the verifier stopped asserting once the fix was included in the JVM
>> build.
>>
>> (Thanks to Coleen for suggesting the fix.)
>>
>> Thanks, Harold
>>
>
More information about the hotspot-runtime-dev
mailing list