Load Barrier Assembly

[Roman Kennke]

>> test %rsi, 0x20(%r15)
>> jne slow_path
>>
>> This is slightly different from what reported in Per's presentations
>> where it was:
>>
>> test %rsi, (0x16)%r15
>> jnz slow_path
>>
>> I'm not an assembly expert, is the second version is a typo?
> 
> Second version has a typo, it should be 0x16(%r15).
> 
>> But the question I have is: what's loaded in r15, and why the bad mask
>> is 32 bytes after that address?
> 
> %r15 is the pointer to thread-local storage:
>   http://hg.openjdk.java.net/jdk/jdk/file/5c7418757bad/src/hotspot/cpu/x86/x86_64.ad#l12887
> 
> Bad mask is at offset 0x20 there:
>   http://hg.openjdk.java.net/jdk/jdk/file/5c7418757bad/src/hotspot/share/runtime/thread.hpp#l147
>   http://hg.openjdk.java.net/jdk/jdk/file/5c7418757bad/src/hotspot/share/gc/z/zThreadLocalData.hpp#l35
> 
>> Can the bad mask be stored in a registry (at the cost of losing one registry)?
> 
> Well, in Shenandoah, we store thread-local gc state the similar way and check it on barrier
> fastpath. We did experiment with putting it into register and the short answer is: losing one of the
> registers means significant drawback when register pressure is high, think heavily unrolled and
> pipelined loop. Additionally, you'd need to handle the restoration of the register value when the
> flag/mask finally changes (happens during safepoint/handshake poll). It is doable, but tedious.

I have the prototype. There are two problems: 1. as you say, we're 
loosing if register pressure is high 2. gc-state reloads (at safepoints, 
call-sites, etc) appear to be more frequent than barriers, which makes 
this approach not very attractive.

Roman