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