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

[Eirik Bjørsnøs]

On Fri, Mar 15, 2024 at 7:54 PM Kevin Walls <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/20240317/7044ccb3/attachment-0001.htm>