[External] : Re: Semantics of CollectedHeap::requires_barriers()

[Ron Pressler]

That code is now undergoing a significant rewrite, but I’m thinking that what’s good for ZGC should work for Shenandoah.
The basic idea is that when the GC first sees derived pointers, it converts them to offsets. With concurrent GCs, this is
done while relying on memory ordering so as not to require synchronization, and thawing detects if the GC has made such
changes by testing if the last oop in the chunk that the GC iterates over, the cont field, is fixed or not.

— Ron


> On 11 Feb 2021, at 22:41, Roman Kennke <rkennke at redhat.com> wrote:
> 
> I see that there is a lot of ZGC specific code paths around oop_oop_iterate() regarding derived pointers. I guess I need to figure out what to do for Shenandoah there.
> 
> We should probably also try to figure out a nicer GC interface for that, instead of sprinkling GC specific code all over the place.
> 
> Thanks,
> Roman
> 
>> 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
>>>> 
>>> 
>