-
Enhancement
-
Resolution: Won't Fix
-
P4
-
21
-
aarch64
-
generic
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.
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.
- links to
-
Review openjdk/jdk/13320