Ping: RFR: JDK-8205523: Explicit barriers for interpreter
erik.osterlund at oracle.com
Wed Jun 27 10:02:08 UTC 2018
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"?
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.
>> Testing: hotspot/tier1, will submit into Mach5 after reviews.
>> Can I please get reviews?
>> Thanks, Roman
More information about the hotspot-dev