[External] : Re: RFD: Can we remove per-thread compiler stats now?

[Kevin Walls]

Right, the existing Deprecated tag had me thinking this was a Java SE interface that had begun the deprecation process.
But it's not a published API.

Maybe we can go further: HotspotCompilationMBean and HotspotInternalMBean look unused.  They are not exposed in the standard PlatformMBeanServer.

While looking for who/what uses these, I also found a recent mailing list thread:
"Question on why sun.management MBeans are not exported?"
https://www.mail-archive.com/core-libs-dev@openjdk.org/msg19878.html

..where the idea of removal also came up.

Thanks
Kevin


From: Eirik Bjørsnøs <eirbjo at gmail.com>
Sent: 17 March 2024 18:43
To: Kevin Walls <kevin.walls at oracle.com>
Cc: serviceability-dev at openjdk.org
Subject: [External] : Re: RFD: Can we remove per-thread compiler stats now?

On Fri, Mar 15, 2024 at 7:54 PM Kevin Walls <kevin.walls at oracle.com<mailto:kevin.walls at oracle.com>> wrote:

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.

Hmm.. But if sun.management.HotspotCompilationMBean is an internal class, it's not defined in the Java SE Specification, right? My understanding when working on similar core-libs cleanups is that internal APIs can be removed directly without the need for a forRemoval step.

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

I think this is already "degraded" in the sense that it does not return useful information (underlying counters are long removed). My intention here is to remove crufty leftover code. I think the best outcome is if we can remove the code so maintainers no longer need to see or reason about it.

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.

This and the rest goes into code and concepts I'm not very familiar with (yet!), so I'm not sure I understand the implications well. But do you think perhaps the whole HotspotCompilationMBean with implementation could be removed? I'm not sure I see any consumers within OpenJDK of this interface?

The role of HotspotCompilationMBean needs more investigation, but basically yes to the idea. 8-)

Good! It seems there is potential for some level of cleanup here, so I'll go ahead and make a PR where we can continue the discussion.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240318/66f56683/attachment-0001.htm>