RFR: JDK-8200623: Primitive heap access for interpreter BarrierSetAssembler/x86

[Erik Österlund]

Hi Roman,

On 2018-05-07 22:31, Roman Kennke wrote:
> JDK-8199417 added better modularization for interpreter barriers.
> Shenandoah and possibly future GCs also need barriers for primitive access.
>
> Some notes on implementation:
> - float/double/long access produced some headaches for the following
> reasons:
>
>    - float and double would either take XMMRegister which is not
> compatible with Register
>    - or load-from/store-to the floating point stack (see
> MacroAssembler::load/store_float/double)
>    - long access on x86_32 would load-into/store-from 2 registers, or
> else use a trick via the floating point stack to do atomic access
>
> None of this seemed easy/nice to do with the API. I helped myself by
> accepting noreg as dst/src argument, which means the corresponding tos
> (i.e. ltos, ftos, dtos) and the BSA would then access from/to
> xmm0/float-stack in case of float/double or the double-reg/float-stack
> in case of long/32bit, which is all that we ever need.

It is indeed a bit painful that in hotspot, XMMRegister is not a 
Register (unlike the Graal implementation). And I think I agree that if 
it is indeed only ever needed by ToS, then this is the preferable 
solution to having two almost identicaly APIs - one for integral types 
and one for floating point types. It beats me though, that in this patch 
you do not address the jni fast get field optimization on x86. It is 
seemingly missing barriers now. Should probably make sure that one fits 
in as well. Fortunately, I think it should work out pretty well.

> I'm passing MO_RELAXED to long access calls to hint that we want atomic
> access or not. I hope that is ok.

Absolutely.

Thanks,
/Erik

>
> Tested: hotspot/jtreg:tier1
>
> http://cr.openjdk.java.net/~rkennke/JDK-8200623/webrev.00/
>
> Can I please get a review?
>
> Thanks, Roman
>