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

[Liang Mao]

On Wed, 8 May 2024 02:39:40 GMT, Liang Mao <lmao at openjdk.org> wrote:

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

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

That's problems with Load barrier because Load nodes in C2 could be rescheduled into other basic blocks which would cause safepoint between Load barrier and Load. Store nodes don't have this problem. This PR doesn't conflict with JEP475 and would reduce the barrier data in very early stage.

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

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