hotspot: support jmm mxbean

[superajun-wsj]

No description provided.

[Copilot]

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.}

[duanyangjing]

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.

[superajun-wsj]

fixed