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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

harold seigel
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

coleen.phillimore

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
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

George Triantafillou
In reply to this post by harold seigel
Hi Harold,

Looks good.  Thanks for fixing this.

-George

On 8/1/2017 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
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

harold seigel
In reply to this post by coleen.phillimore
Hi Coleen, George,

Thanks for the reviews!

Harold


On 8/1/2017 5:57 PM, [hidden email] 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
>>
>

Loading...