RFR: 8305523: Some StoreStore barriers in the interpreter are unnecessary after JDK-8205683

[SUN Guoyun]

On Tue, 4 Apr 2023 12:11:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After JDK-8205683, InterpreterRuntime::_new() and InterpreterRuntime::newarray() eventually calls Atomic::release_store() to prevent reordering of stores for object initialization with stores that publish the new object. The stack call is as follows
>> 
>> Atomic::release_store((Klass**)raw_mem, k)
>> oopDesc::release_set_klass(HeapWord* mem, Klass* k)
>> oop MemAllocator::finish(HeapWord* mem)
>> ArrayKlass::cast(klass)->allocate_arrayArray(1, length, THREAD);
>> oopFactory::new_objArray(klass, size, CHECK);
>> InterpreterRuntime::anewarray(JavaThread* current, ConstantPool* pool, int index, jint size)
>> 
>> So StoreStore barriers trailing behind bytecode _new, newarray, anewarray is unnecessary.
>> 
>> aarch64, riscv and ppc have the same problem.
>
> I don't think this change is correct. The release_store and the storestore are doing two different jobs. The basic sequence is:
> 
> <init some stuff>
> release_store klass-ptr
> <possibly other stuff>
> storestore
> store newly allocated object into field
> 
> without the `storestore` the final store can float up before the store of klass-ptr.

Thanks @dholmes-ora for explaining, you are right, I know what storestore does. But do you know why does store klass_ptr need a release barrier? I found that store klass_ptr does not have a release barrier in C1/C2 compiler. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp#L172

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

PR Comment: https://git.openjdk.org/jdk/pull/13320#issuecomment-1498564077