On Wed, 15 Oct 2025 11:01:53 GMT, Tobias Hartmann <[email protected]> wrote:

>> @TobiHartmann Hi Tobias, I am having difficulties understanding how our 
>> current flat accesses deal with GC barriers. IIUC, every time an access is 
>> made to a memory region that may contain an oop, we need a GC barrier (which 
>> itself may be a nop). However, looking at our current implementation, I only 
>> see that being handled for G1GC with `StoreLSpecialNode`. For Serial, 
>> Parralel, and Shenandoah, the access is made as if the memory is a long, 
>> which I assume would not trigger any GC barrier. When I try to add an 
>> assertion that a flat access that contains an oop cannot be made for 
>> anything other than G1GC, the assert fires.
>
> @merykitty Hi Quan-Anh, sorry for the delay, I missed this message. 
> 
>> I only see that being handled for G1GC with StoreLSpecialNode
> 
> G1 is handled specially because of late barrier expansion:
> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/opto/inlinetypenode.cpp#L660-L693
> 
> For the other GCs, we emit the barriers already during parsing (the 
> information is propagated via `C2ParseAccess`):
> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.cpp#L40-L53
> and
> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/gc/shared/c2/modRefBarrierSetC2.cpp#L59-L70
> 
> I added this with https://github.com/openjdk/valhalla/pull/1318 and as 
> mentioned in the PR, this is a bit of a hacky first implementation. We should 
> refactor / improve this later (tracked by 
> [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865)).
> 
> Does that help?
> 
> If you get a chance, could you merge this PR with latest `lworld`? We see 
> some issues that look similar to this and would like to verify if your patch 
> helps. Thanks!

@TobiHartmann Thanks a lot for your help, I am working on this. However, I 
think that would mean Shenandoah is broken as I see no similar handling in 
`ShenandoahBarrierSetC2`?

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1518#issuecomment-3408973513

Reply via email to