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

[Erik Österlund]

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

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

I think that store capturing of initializing stores already removes most of the barriers of this category. We do that a bit later on. We find initializing stores onto newly allocated objects, and replace the store with barriers, with a store without barriers. That one usually elides a large portion of store barriers. Did you find any example where you have a newly allocated object with stores that are not initializing, hence not elided, which unnecessarily invoked a pre-write barrier, but not a post-write barrier? Just trying to find out what the problem space is, that this fixes.

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

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