Patch MXBean to support virtual threads #15956
Conversation
|
@fengxue-IS FYI |
thallium
force-pushed
the
mxbean
branch
2 times, most recently
from
170d39b
to
dd76bd4
Compare
thallium
changed the title
There was a problem hiding this comment.
minor formating suggestion, rest lgtm.
@thallium as the change in thrinfo.c may impact other code that makes use of it to retrieve lock info, can you verify this change doesn't break any of our existing tests (sanity.functional / sanity.openjdk / extended.functional + jvmti test from the serviceability suite)
|
sanity.functional and extended.functional test passed, sanity.openjdk failed to start, not sure if it's a configuration problem |
There was a problem hiding this comment.
LGTM
Per offline discussion, this change in thrinfo didn't impact testing that have been fixed in #15914 (comment)
@babsingh Can you take a look please.
|
Also, full-stops are missing in the commit message. See the updated PR description. |
Use carrierThreadObject instead of threadObject for Java 19. For thread with a virtual thread mount that is waiting on a lock, we should return the virtualthreadobject as lock object/owner. Signed-off-by: Gengchen Tuo <gengchen.tuo@ibm.com>
|
jenkins test sanity amac,win jdk19,jdk11 |
Fixes the typo introduced in eclipse-openj9#15956. targetThread should be used instead of currentThread for retrieving the threadObject. Related: eclipse-openj9#14538 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
Use carrierThreadObject instead of threadObject for Java 19.
For thread with a virtual thread mount that is waiting on a lock,
we should return the virtual thread object as lock object/owner.
Fixes #15941