-
Notifications
You must be signed in to change notification settings - Fork 729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor VirtualThread synchronization design #16855
Conversation
8e773b1
to
91fb21f
Compare
91fb21f
to
efdec55
Compare
efdec55
to
3f066c7
Compare
Update
|
That's fine for the JVMTI code but will probably be unuseably slow for any hot code path. EVMA is an extremely expensive operation. |
Currently JVMTI suspend/resume all is the only case where the RW lock is using writer access, so I assume by switching to EMVA will just remove the need for any locking for non-jvmti path |
3f066c7
to
a7ac1a1
Compare
Have you measured CPU usage before and after this change? Spinning is OK for short-lived operations, but I suspect the CPU usage will spike heavily with this solution. |
a7ac1a1
to
c934c05
Compare
updated to the EVMA design, perf result 7x better on nocompressedrefs, 20% perf better on compressedrefs |
008bd24
to
af3fa02
Compare
ef82390
to
52dddc4
Compare
…ed thread Signed-off-by: Jack Lu <Jack.S.Lu@ibm.com>
Signed-off-by: Jack Lu <Jack.S.Lu@ibm.com>
Signed-off-by: Jack Lu <Jack.S.Lu@ibm.com>
3fe37ae
to
7873bf8
Compare
addressed all review comments, locally compile/tested against JTReg stress test on x86 linux. |
jenkins test sanity.functional,extended.functional,sanity.openjdk,sanity.system,extended.system xlinux jdk19 |
test failure due to assertion added in #16713
This code is incorrect since when a yielded continuation gets freed by GC due to being unreachable, this assertion will fail (though state actually correctly reflected). This assertion made the assumption that unfinished vthread object will be kept alive by the VM's PS: I think the only thing we can assert during freeContinuation is that the continuation cannot be mounted (otherwise we are deleting a carrierThread's data) |
PR testing would need to depends on extension repo changes (something like)
|
@fengxue-IS Are you going to fix the assertion here? Is there any reason ibmruntimes/openj9-openjdk-jdk19#83 can't be merged? |
I can fix the assertion in this pr, just want to confirm with lin that i correctly understand the reason for having the assertion originally.
the extension change is co-dependent on this pr ( |
Continuation must be unmounted/not being scanned when free. Signed-off-by: Jack Lu <Jack.S.Lu@ibm.com>
5801f93
to
c50c552
Compare
jenkins test sanity.functional,extended.functional,sanity.openjdk,sanity.system,extended.system xlinux jdk19 depends ibmruntimes/openj9-openjdk-jdk19#83 |
I won't merge this if the testing passes due to the dependency. Someone who is a committer in both repos will have to do it. |
Sure Ill do it |
build failed due to javadoc compile error, pending fix #17077 |
jenkins test sanity.functional,extended.functional,sanity.openjdk,sanity.system,extended.system xlinux jdk19 depends ibmruntimes/openj9-openjdk-jdk19#83 |
j9object_t *liveVirtualThreadList; | ||
omrthread_monitor_t liveVirtualThreadListMutex; | ||
volatile BOOLEAN inspectingLiveVirtualThreadList; | ||
UDATA virtualThreadLinkNextOffset; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see an update to DDR code to deal with the removal of virtualThreadLinkNextOffset
; as a result, the !vthreads
command is now broken: #17084 tracks that problem.
VThreadList lock contention fixed by eclipse-openj9/openj9#16855 Signed-off-by: Jack Lu <Jack.S.Lu@ibm.com>
VThreadList lock contention fixed by eclipse-openj9/openj9#16855 Signed-off-by: Jack Lu <Jack.S.Lu@ibm.com>
Removes use of
liveVirtualThreadList/liveVirtualThreadListMutex
in the VM and rely on GC's Continuation list.This design uses an atomic based RW lock with busy waiting for vthread access during mounted/unmount transition.
Global access in JVMTI is a slow path and done through Exclusive VM Access which doesn't require additional locking.
mutual dependency:
jdk19: ibmruntimes/openj9-openjdk-jdk19#83
jdk20: ibmruntimes/openj9-openjdk-jdk20#32
jdknext: ibmruntimes/openj9-openjdk-jdk#574
Fixes: #16728
Signed-off-by: Jack Lu Jack.S.Lu@ibm.com