[aarch64-port-dev ] Against hidden read barriers in intrinsics

[Roman Kennke]

Am 20.06.2018 um 18:01 schrieb Dmitrij Pochepko:
> Hi,
> 
> (I'm not a shenandoah expert and might get things wrong, so correct me
> in this case).
> 
> We need to resolve brook pointers before accessing any data, potentially
> causing copy into to-space.
> 
> If that's the case, then fix for "JDK-8203157: Object equals abstraction
> for BarrierSetAssembler" (
> http://hg.openjdk.java.net/jdk/jdk/rev/8434981a4137 ) seems to be wrong.
> 
> Specifically:
> hg.openjdk.java.net/jdk/jdk/annotate/8434981a4137/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l5141
> 
> 
> This code (lines 5125-5134) is a bit tricky. It checks pointers for
> non-null value and load array length from array header to fire load
> instruction into ld pipelines as early as possible. And *after* that
> checks pointers for equality in parallel with loads, because such code
> pattern shows better result. In case of shenandoah it can cause load of
> potentially uninitialized data via brook pointers.
> 
> Do I understand it correctly?

I am not sure that I understand it correctly :-)

Are you saying it might be wrong to load arraylengths from a1 and a2,
because they have not been resolved via brooks ptr yet? This is a very
special case because arraylength is immutable and it doesn't matter
which copy we read it from. So yeah, I think the code is still correct
with respect to the array length. Was that what you are trying to say/ask?

Roman