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

[Roman Kennke]

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