Add fence on yield to preserve HB for lock reservation #16023
Conversation
|
@gacholio could this be an issue on x86 as well? Currently, I dont think so |
|
jenkins test sanity amac jdk19 |
tajila
changed the title
|
I have no context here - what might HB refer to? |
|
Whether this is necessary or not, excluding it on x86 is pointless - yield is already a long operation so an extra fence will never be noticeable. |
|
Would be nice to see a detailed description of what you think the problem here might be. |
HB refers to happens-before relationship. There is a requirement in the memory model that a HB relationship is eforced between synchronization blocks. On PPC lock reservation is on by default, this means we dont do a memory barrier when entering a reserved lock. It works in this case because so long as the thread who owns the reservation is entering the lock, HB happens naturally. If a different thread wants to acquire the lock then the reservation is cancelled which performs a full memory barrier. With Loom this is complicated by the fact that different virtual threads can run on the same j9vmthread. So virtualthread#1 running on j9vmthread#1 can reserve objectA. Later on, it can yield allowing virtualthread#2 to run on j9vmthread#1. If virtualthread#2 acquires objectA (it will own reservation since j9vmthread determines ownership)on a different core, there is a chance that it will not see the update made by virtualthread#1 since there was no memory barrier required when acquire objectA. So we need to insert a barrier everytime virtualThread yields to ensure a HB between virtualThreads acquire the same lock when lock reservation is enabled.
I added a description in the code. If its not sufficient I can elaborate more. |
Signed-off-by: Tobi Ajila <atobia@ca.ibm.com>
|
jenkins compile zlinux jdk19 |
Add fence on yield to preserve HB for lock reservation
Signed-off-by: Tobi Ajila atobia@ca.ibm.com