RFD: Can we remove per-thread compiler stats now?

[Kevin Walls]

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-retn at openjdk.org> On Behalf Of Eirik Bjørsnøs
Sent: 14 March 2024 17:06
To: serviceability-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240315/85d30546/attachment-0001.htm>