-
Notifications
You must be signed in to change notification settings - Fork 8
hotspot: support jmm mxbean #68
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
base: jdk25u-target8
Are you sure you want to change the base?
Conversation
cdf0d1c
to
2f3480f
Compare
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.
Pull Request Overview
Adds JMM MXBean compatibility for HOTSPOT_TARGET_CLASSLIB == 8 by introducing a JDK 8-specific JMM interface, version handling, and related helper functions.
- Introduces a JDK 8-specific JMM interface (struct, functions, and version handling).
- Refactors thread-dump logic into a common helper and adds a JDK 8 wrapper without maxDepth.
- Exposes VM input arguments (string and array) and a JDK 8 diagnostic command-argument info entry point.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
File | Description |
---|---|
src/hotspot/share/services/management.cpp | Adds JDK 8-specific JMM functions, refactors thread-dump into a common helper, adjusts version return and optional support, and wires a JDK 8 interface table. |
src/hotspot/share/include/jmm.h | Defines JDK 8-specific JMM version, optional support bit, and the JDK 8 interface struct and signatures. |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
// locked_synchronizers - if true, dump locked JSR-166 synchronizers | ||
// | ||
JVM_ENTRY(jobjectArray, jmm_DumpThreads(JNIEnv *env, jlongArray thread_ids, jboolean locked_monitors, | ||
JVM_ENTRY(jobjectArray, dump_threads_common(JNIEnv *env, jlongArray thread_ids, jboolean locked_monitors, |
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.
dump_threads_common
is made a JVM_ENTRY
, and then called in a JVM_ENTRY
jmm_DumpThreads
. It is dangerous to call a JVM_ENTRY
from another JVM_ENTRY
.
From the macro definition:
#define JVM_ENTRY(result_type,header) extern "C" { result_type JNICALL header { JavaThread* thread=JavaThread::thread_from_jni_environment(env); MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, thread)); ThreadInVMfromNative __tiv(thread); DEBUG_ONLY(VMNativeEntryWrapper __vew;) VM_ENTRY_BASE(result_type, header, thread)
There is thread state transition code ThreadInVMfromNative __tiv(thread)
when calling from native to jvm code. The first JVM_ENTRY
call is fine, the second JVM_ENTRY
could be problematic because thread is already in state vm.
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.
fixed
e475575
to
c7835b6
Compare
No description provided.