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

Dean Long dlong at openjdk.org
Tue Jan 23 03:21:28 UTC 2024


On Mon, 22 Jan 2024 10:02:41 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> How would the graph look like if there were memory barriers? Would there not be something on the memory graph or control graph which is neither a Store nor a RangeCheck?

Yes, I think so.  See for example GraphKit::insert_mem_bar().

> Any what exactly is your concern about `MemNode::unordered`? Would you mind explaining or giving some examples?

Any stores with explicit Release semantics, for example, probably expect that ordering to preserved.  It looks like such a store can be generated using Unsafe.putByteRelease().  So I would think that the only stores that can take part in this optimization should be using "unordered".  How would your optimization apply to the following cases?

case 1:
Unsafe.putByteRelease(array1, offset+0, 'A');
Unsafe.putByteRelease(array1, offset+1, 'A');

case2:
Unsafe.putByteRelease(array1, offset+0, 'A');
Unsafe.putByteRelease(array1, offset+3, 'A');
Unsafe.putByteRelease(array1, offset+1, 'A');

In case 1, I don't think it's safe to turn this into a 16-bit store unless the store is atomic, otherwise another thread might see the writes in the wrong order.  Likewise for case 2, another thread shouldn't be able to observe the writes in the wrong order.

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

PR Comment: https://git.openjdk.org/jdk/pull/16245#issuecomment-1905223447


More information about the hotspot-compiler-dev mailing list