RFR: JDK-8200623: Primitive heap access for interpreter BarrierSetAssembler/x86
erik.osterlund at oracle.com
Mon Jun 4 15:27:07 UTC 2018
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
> - float and double would either take XMMRegister which is not
> compatible with Register
> - or load-from/store-to the floating point stack (see
> - 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.
> Tested: hotspot/jtreg:tier1
> Can I please get a review?
> Thanks, Roman
More information about the hotspot-dev