RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v9]

[Roberto Castañeda Lozano]

On Sun, 25 Aug 2024 06:15:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Roberto Castañeda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass oldval to the pre-barrier in g1CompareAndExchange/SwapP
>
> src/hotspot/share/opto/memnode.cpp line 3468:
> 
>> 3466:   // Capture an unaliased, unconditional, simple store into an initializer.
>> 3467:   // Or, if it is independent of the allocation, hoist it above the allocation.
>> 3468:   if (ReduceFieldZeroing && ReduceInitialCardMarks && /*can_reshape &&*/
> 
> It's not obvious to me how this is related to the late barrier changes.

I agree this change is not obvious and deserves an explanation.

With `ReduceInitialCardMarks` disabled, a store to a newly allocated object requires a post-barrier. In current mainline code, the post-barrier is expanded early, which allows the store-capturing transformation (a first step to avoid needless zeroing in object initialization) to move the store and its post-barrier apart: the store goes into the initialization sequence of the recently allocated object, whereas the post-barrier itself remains outside. Here is an example in pseudo-code of this transformation for early-expanded GC barriers:


(before store capturing):

allocate object o
start initialization of o
...
o.f <- 0
...
end initialization of o
memory barrier (store-store)
o.f <- new-val
post-barrier of o.f <- new-val

(after store capturing):

allocate object o
start initialization of o
...
o.f <- new-val
...
end initialization of o
memory barrier (store-store)
post-barrier of o.f <- new-val


In late barrier expansion however, the post-barrier is an implicit, inseparable part of the store, so if we have stores with post-barriers we have no other choice than leaving them outside the initialization section. To enforce this, the change simply disables store-capturing analysis in the `!ReduceInitialCardMarks` case, which is the only case where we might find stores with post-barriers on recently allocated objects. A perhaps more principled solution might be extending store-capturing analysis to reject stores with late-expanded barriers. I will give it a try.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1738693695