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

[Roman Kennke]

Hi Erik,

>> 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.

As mentioned in the review thread for JDK-8203172, we in Shenandoah land
decided to disable JNI fastgetfield stuff for now. I am not sure whether
or not we want to go through access_* anyway? It's probably more
consistent if we do. If we decide that we do, I'll add it to this patch,
if we don't, I'll rip it out of JDK-8203172 :-)

Thanks, Roman