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