Hi, Sounds like a good plan.
I don't think it causes any problems, we aren't creating them now. These counters are in jdk8u. The jcmd "jcmd PID PerfCounter.print" shows them when attaching to a JDK8 process. But if nothing relies on them being there… https://openjdk.org/jeps/277 "An API element should not be removed from the Java SE specification unless it has been delivered with an annotation of @Deprecated(forRemoval=true) in a previous version of Java SE." So deprecations need to be "upgraded" to forRemoval, this will take a few updates to get them removed. HotspotCompilationMBean: @Deprecated public java.util.List<CompilerThreadStat> getCompilerThreadStats(); .. need to consider whether a method is removed or just "degraded" (not return any information, or throw). That said, I see sun.management.CompilationImpl[java.lang:type=Compilation] ..rather than HotspotCompilation. ManagementFactoryHelper.java: getCompilationMXBean() specifically creates a CompilationImpl, users don’t normally see the HotspotCompilation mbean. Elsewhere in that file, registerInternalMBeans() does: 517 // CompilationMBean may not exist 518 if (getCompilationMXBean() != null) { <-- returns new CompilationImpl(jvm); 519 addMBean(mbs, getHotspotCompilationMBean(), <-- returns new HotspotCompilation(jvm) 520 HOTSPOT_COMPILATION_MBEAN_NAME); <-- which is "sun.management:type=HotspotCompilation" 521 } HotspotInternal (HotspotInternalMBean) calls ManagementFactoryHelper.registerInternalMBeans(server). HotspotInternal is a non-public API, and might be the way of acquiring a HotspotCompilation. The role of HotspotCompilationMBean needs more investigation, but basically yes to the idea. 8-) Thanks Kevin From: serviceability-dev <serviceability-dev-r...@openjdk.org> On Behalf Of Eirik Bjørsnøs Sent: 14 March 2024 17:06 To: serviceability-dev@openjdk.org Subject: RFD: Can we remove per-thread compiler stats now? Hello, Per-thread compiler performance counters were removed in JDK-8134607 [1] (JDK 9). The corresponding sun.management API was marked @Deprecated since it no longer returns any useful counter data. Has time come to remove this API now? My understanding is that since sun.management is an internal package this should be low risk. But this being JMX-related, is there maybe some concern to this being used in some remote/RMI scenario? If not, I'd like to propose a PR to remove the following: * Class sun.management.CompilerThreadStat * Nested class sun.management.HotspotCompilation.CompilerThreadInfo * Field sun.management.HotspotCompilation.threads and its initialization * Method sun.management.HotspotCompilation.getCompilerThreadStats() and its definition in HotspotCompilationMBean Let me know what you think Cheers, Eirik :-) [1] https://bugs.openjdk.org/browse/JDK-8134607
