Skip to content

Conversation

superajun-wsj
Copy link
Collaborator

No description provided.

@superajun-wsj superajun-wsj force-pushed the jdk25u-target8-jmm-mxbean-fix branch from cdf0d1c to 2f3480f Compare October 17, 2025 06:43
Copy link

@Copilot Copilot AI left a 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,
Copy link
Collaborator

@duanyangjing duanyangjing Oct 21, 2025

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@superajun-wsj superajun-wsj force-pushed the jdk25u-target8-jmm-mxbean-fix branch 2 times, most recently from e475575 to c7835b6 Compare October 21, 2025 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants