RFR 8180627: gc/gctests/Steal/steal001: guarantee(cp->cache() == NULL) failed

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Tue Aug 1 21:57:57 UTC 2017


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