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

[Roman Kennke]

Read barriers in Shenandoah are just a single load instruction. It's either loading from L1 cache (self-reference) or warming up for subsequent read. Write barriers OTOH are always testing+ branching on fast-path, and possibly copying on slow-path. This can be particularly bad if it encounters a large-ish array. Given that reads are much more frequent than writes, we'd like to avoid that. Consider array copy. Normally we need RB on src and WB on dst. If we were to follow your suggestion, we'd probably first copy src (via WB), then copy dst (via WB, usually doesn't happen because dst is new) and then copy src *again*.

I was already cringing when we did that in runtime. I don't think the overhead API-wise and brain-wise is as bad as you make it (or maybe it's just me because I'm so into it..?). We could *probably* do this in interpreter. I would not want to have this discussion again in c1 and c2 though, in compilers it's provably performance relevant.

Roman

Am 27. Juni 2018 12:02:08 MESZ schrieb "Erik Österlund" <erik.osterlund at oracle.com>:
>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
>>>
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.