RFR: JDK-8221766: Load-reference barriers for Shenandoah

[Andrew Haley]

On 4/5/19 1:50 PM, Roman Kennke wrote:
>>> Does all that answer your question? :-)
>>
>> Sure. One thing that always bothered me about the write barrier was that
>> it looked fantastically expensive: all of the CPU state was pushed, and
>> there is a lot of CPU state on AArch64. I never did understand why we can't
>> have a fast path for that.
> 
> The write-barrier/LRB slowpath is not actually very hot, and with LRB it 
> is even less hot. We did have a fast-path for that, you actually wrote 
> it yourself, but it didn't make much difference (or any difference at 
> all) in overall throughput.

Yeah, I remember. I just wish I understood why the write barrier is so
cold. I mean, you're racing with the GC threads, right? So if we load
a stale pointer we have to promote the object ... and apparently that
is extremely rare. Is that true even at times of heavy load? I don't
get it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671