RFR: 8331711: G1 doesn't need pre write barrier for stores from new allocated objects [v2]

[Liang Mao]

On Wed, 8 May 2024 01:38:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 199:
>> 
>>> 197:     assert(val_type != nullptr, "need a type");
>>> 198: 
>>> 199:     if (use_ReduceInitialCardMarks() && obj == kit->just_allocated_object(kit->control())) {
>> 
>> This isn't correct.  It doesn't ensure there aren't any stores to the same
>> location between the allocation and this store that might need to be tracked.
>> g1_can_remove_pre_barrier (below) does that.
>
> We've had lots of problems with safepoints sneaking into unexpected places.
> That's why (Gen)ZGC uses late barrier expansion.  That's also one of the
> motivations for https://openjdk.org/jeps/475.

> This isn't correct. It doesn't ensure there aren't any stores to the same location between the allocation and this store that might need to be tracked. g1_can_remove_pre_barrier (below) does that.

Hi Kim, g1_can_remove_pre_barrier is not sufficient which only eliminates stores with previous "null" value from object initialization. But actually no matter the original value is null or not stores to new allocated objects don't need SATB barrier at all. SATB pre-write barriers are delete protection barrier to protect reference disconnected from graph which is not necessary for new allocated objects. Any stored pointers into new alllocated objects are guaranted not white. GenZGC uses the same way the store barrier could be removed only if allocations dominate without safepoint blocking. The pre-write barrier elimination should be same to post-write barrier for new allocated objects.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19098#discussion_r1593309336