[External] : Re: Semantics of CollectedHeap::requires_barriers()
Roman Kennke
rkennke at redhat.com
Thu Feb 11 20:50:26 UTC 2021
Thanks again for the explanations!
I believe the assert that I see comes from a bad derived oop. However,
in InstanceStackChunkKlass::barriers_for_oops_in_frame() I don't see
that derived-oops are handled *at all*. I believe this means that if we
have a derived oop there that pointed to from-space, it would not get
updated to to-space derived-oop. Or am I missing something?
Thanks,
Roman
> When frames are thawed from a chunk, then if and only if that chunk requires_barriers, then InstanceStackChunkKlass::barriers_for_oops_in_frame
> invokes any store barriers on the thawed oops.
>
> — Ron
>
>> On 10 Feb 2021, at 19:08, Roman Kennke <rkennke at redhat.com> wrote:
>>
>>
>>>> However, we might need barriers when copying frames out of the stack chunk (e.g. when thawing frames), because then we'd be loading from oop locations. Is this taken care of already somehow?
>>> If you need barriers when thawing, then requires_barriers must return false, and then it’s taken care of.
>>
>> Can you explain to me how that is supposed to work? If I understand it correctly, the frozen frame can contain any number of oops. When copying back the chunk into the stack, the GC must ensure:
>> 1. That it copies back the correct copy of StackChunk (this might not actually be very relevant because the StackChunk is immutable, and thus both from-space and to-space copy should be equivalent).
>> 2. More importantly, it must update/heal all oops in the chunk, otherwise it violates the strong to-space variant.
>>
>> How and where is this achieved?
>>
>> I am asking this, because I still see a failing Fuzz.java test:
>>
>> http://cr.openjdk.java.net/~rkennke/hs_err_pid623629.log
>>
>> and I suspect that thawing is not working correctly.
>>
>> I would expect some sort of GC interface to achieve the above points, and conceptually it seems very similar to clone-barriers. But I don't see any of this, except NativeAccess<>::oop_load() calls, which definitely cannot achieve the desired effect. Or maybe no other GC has required such treatment yet, and therefore that's missing?
>>
>> Roman
>>
>
More information about the loom-dev
mailing list