RFR (S) 8251336: Shenandoah: assert "only get here when SATB active" after JDK-8244997
Aleksey Shipilev
shade at redhat.com
Tue Aug 11 14:15:38 UTC 2020
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 :)
--
Thanks,
-Aleksey
More information about the hotspot-dev
mailing list