Ping: RFR: JDK-8205523: Explicit barriers for interpreter

[Erik Österlund]

Hi Roman,

How important is it for you to distinguish resolve for write vs read? 
What would the impact be for you if we were to stick with just 
"resolve", the way we did in runtime?
I think that for the non-GC developers, it gets more tricky if they have 
to remember not to perform any writes because somewhere further up in 
the call hierarchy, the oop was only resolved for reading. Or that any 
reads used have to be non-volatile, or you risk running into a subtle 
IRIW situation (even on TSO hardware) due to having multiple reads 
riding on the same read resolve, potentially causing inconsistencies. It 
won't be a problem in the places you inserted the read resolves to now.

However, by letting resolve always do what you refer to as write resolve 
(which we do in the runtime now), the user does not need to think about 
this, and the conceptual overhead for the non-GC expert is lower. The 
cost of keeping it simpler seems low in the interpreter. In my 
experience, this kind of optimization does not pay off in the interpreter.

So how would you feel about sticking with just "resolve"?

Thanks,
/Erik

On 2018-06-27 10:45, Roman Kennke wrote:
>> Hi all,
>>
>> A number of operations cannot reasonably make use of the Access API but
>> require explicit read- and write-barriers for GCs like Shenandoah that
>> need to ensure to-space consistency. Examples are monitor-enter/-exit
>> and some intrinsics.
>>
>> The change adds APIs to BarrierSetAssembler (x86 and aarch64) to support
>> these kinds of explicit barriers, and the necessary calls in relevant
>> places. The default implementation does nothing. These barriers have
>> been found and tested over several years in Shenandoah.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8205523
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.00/
>>
>> Testing: hotspot/tier1, will submit into Mach5 after reviews.
>>
>> Can I please get reviews?
>>
>> Thanks, Roman
>>
>