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

[Roman Kennke]

Am 5. April 2019 18:17:09 MESZ schrieb Andrew Haley <aph at redhat.com>:
>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.

We only have to enter the slowpath if:
- obj is != NULL
- evacuation is in progress
- obj is in cset (smallish subset of all regions)
- obj is not evacuated already

We check all this in the fast-/mid-path before diving into runtime for the slowpath. Also, if obj is already evacuated, we resolve it in the midpath and are done.

Roman

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