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

[David Holmes]

On Tue, 4 Apr 2023 07:23:31 GMT, SUN Guoyun <duke 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.

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

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