RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997

Coleen Phillimore coleen.phillimore at oracle.com
Tue Aug 11 14:29:47 UTC 2020



On 8/11/20 10:15 AM, Aleksey Shipilev wrote:
> On 8/11/20 3:58 PM, Kim Barrett wrote:
>>> On Aug 11, 2020, at 9:56 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>
>>>> On Aug 11, 2020, at 7:40 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>>
>>>> Summary: Release OopStorage oops outside a safepoint.
>>>>
>>>> Tested with tier1-6.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8251336.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251336
>>>>
>>>> Thank you to Zhengyu for alerting me about this issue.
>>>>
>>>> Coleen
>> BTW, I haven’t actually looked, but I think there’s a good chance this also affects G1.
> Yes, it does not look Shenandoah-specific. The failure is on the NativeAccess::oop_store/SATB path.
>
> It reproduces with Shenandoah because it has lots of asserts on SATB paths, it sometimes calls
> enqueue with NULL oops (which accidentally what is being passed there as "old" value), it has a very
> aggressive test that exercises destroyed threads (which had a fair share of baldness-inducing
> Shenandoah-specific bugs before, thus named gc/shenandoah/TestEvilSyncBug.java).
>
> Coleen, you might consider changing the synopsis a bit :)

Ok, I will.
Coleen
>



More information about the hotspot-dev mailing list