[External] : Re: RFD: Can we remove per-thread compiler stats now?
Kevin Walls
kevin.walls at oracle.com
Mon Mar 18 13:31:37 UTC 2024
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>
More information about the serviceability-dev
mailing list