RFR: JDK-8209667: Explicit barriers for C1/LIR

[Roman Kennke]

Am 20.08.2018 um 15:59 schrieb Roman Kennke:
> Hi Erik,
> 
> thanks for reviewing!
> 
>> Looks good in general. A few minor things though:
>>
>> 1) I think IN_HEAP should be removed from the access_resolve callsites
>> (because IN_HEAP is for differentiating if an access hits inside or
>> outside of the heap, and this is seemingly orthogonal).
> 
> Good point. Fixed.
> 
>> 2) I see you used the LIRAccess object to wrap the context of the
>> resolution. However, in this case since this is not an access, this
>> seems to cause more trouble than it solves. The only parameters that
>> apply is the address (which could be represented with a LIROpr), and the
>> decorators. So I think I would just pass those two parameters around in
>> the BarrierSetC1 backend, instead of passing around the baked LIRAccess
>> object with dummy parameters.
> 
> We also need the LIRGenerator* and CodeEmitInfo* (see below). Would you
> prefer to pass 4 arguments around? I am ok with either approach, and
> passing for args is probably easier to understand than passing one
> opaque LIRAccess&. Whatever you prefer.
> 
>> 3) What do you need the CodeEmitInfo parameter for? It doesn't seem to
>> be used anywhere. Or is it?
> 
> I believe we use it in case the obj is not known to be not NULL, in
> which case we need to emit null-checks.
> 
> I'll post an updated webrev once we agree on #2.

ok, let's have a look at it:

differential:
http://cr.openjdk.java.net/~rkennke/JDK-8209667/webrev.01.diff/
full:
http://cr.openjdk.java.net/~rkennke/JDK-8209667/webrev.01/

if you think that's better than to use the opaque access stuff, I'm fine
with it. let me know how you like it.

Cheers, Roman