RFR: 8318446: C2: optimize stores into primitive arrays by combining values into larger store [v17]

[Aleksey Shipilev]

On Thu, 7 Mar 2024 15:23:45 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I don't think it matters, no. Do you see a scenario where it would matter?
>> 
>> My argument:
>> It is safe to do the stores after the RC rather than before it. And if the RC trap relies on the memory state of the stores that were before the RC, then those stores simply don't lose all their uses, and stay in the graph.
>> After all, we only remove the "last" store by replacing it with the merged store, so the other stores only disappear if they have no other use.
>
> Is there a chance then that we store to the same element twice (once with the store that we wanted to remove but haven't and the merged store)? I don't think repeated stores like this happen anywhere else as a result of some transformation. Would it be legal wrt the java specs? Can it be observed from some other thread? I think it would be better to not have to answer these questions and find a way to do the transformation in a way that guarantees the same element is not stored to twice.
> Can the transformation be delayed until range check smearing has done its job?

> Is there a chance then that we store to the same element twice ... Would it be legal wrt the java specs?

AFAIU, introducing writes that do not exist in original program is an easy way to break JMM conformance. If we merge the writes, we have to make sure the old writes are not done. You _need_ to run jcstress on this change, at very least.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16245#discussion_r1516374382