RFD: Remove Hotspot-internal MBeans from sun.management

[Kevin Walls]

Hi,

8328618: HotspotInternalMBean should be removed
https://bugs.openjdk.org/browse/JDK-8328618

I looked a bit further and logged this, with notes on what the HotSpotXX MBeans actually do.  It is almost all about providing a Java MBean interface to perf counters. HotspotThread additionally provides thread count and thread CPU usage by “internal” threads, although the definition of that is maybe unclear.

Thanks
Kevin


From: Kevin Walls
Sent: 20 March 2024 10:53
To: Mandy Chung <mandy.chung at oracle.com>; Eirik Bjørsnøs <eirbjo at gmail.com>; serviceability-dev at openjdk.org
Cc: Volker Simonis <volker.simonis at gmail.com>; Alan Bateman <alan.bateman at oracle.com>
Subject: RE: RFD: Remove Hotspot-internal MBeans from sun.management


Yes, I looked into it a little since you raised the previous issue, that looks like the right direction.

HotspotInternalMBean should be removed (an undocumented, unsupported and experimental interface)

HotspotInternalMBean creates: sun.management….
HotspotClassLoading
HotspotMemory
HotspotRuntime
HotspotThread
HotspotCompilation

These have a peculiar way of accessing that we do not document as far as I can see.

It would be good to look at whether anything in there is not adequately available by other MBeans, or jstat, or any other mechanism.

Thanks
Kevin


From: Mandy Chung <mandy.chung at oracle.com<mailto:mandy.chung at oracle.com>>
Sent: 19 March 2024 16:48
To: Eirik Bjørsnøs <eirbjo at gmail.com<mailto:eirbjo at gmail.com>>; serviceability-dev at openjdk.org<mailto:serviceability-dev at openjdk.org>
Cc: Volker Simonis <volker.simonis at gmail.com<mailto:volker.simonis at gmail.com>>; Kevin Walls <kevin.walls at oracle.com<mailto:kevin.walls at oracle.com>>; Alan Bateman <alan.bateman at oracle.com<mailto:alan.bateman at oracle.com>>
Subject: Re: RFD: Remove Hotspot-internal MBeans from sun.management


Would a PR to remove these APIs be welcome?

Good with me.

Mandy
On 3/19/24 9:41 AM, Eirik Bjørsnøs wrote:

Hi,

Last September, Volker shared the observation that we have Hotspot-internal MBeans in sun.management which are strongly encapsulated and not used internally by OpenJDK besides their unit tests:

https://www.mail-archive.com/core-libs-dev@openjdk.org/msg19878.html<https://urldefense.com/v3/__https:/www.mail-archive.com/core-libs-dev@openjdk.org/msg19878.html__;!!ACWV5N9M2RV99hQ!KfW2PiXn5Gb38tJmxUNxLW_fhwy1H7NijeBmgeWH0ZWNw6QriJmDY_ZD5miuxMQq9q0Rl_k6ZOdb-b0$>

A summary of the email thread:

Mandy pointed out:

We added these HotSpot internal MBeans in JDK 5 to expose the internal metrics.  Most of these internal metrics are exposed via jstat tool too.   We didn't receive much feedback regarding these HotSpot internal MBeans.    Removing them is fine and good cleanup effort.

Alan made a similar point:

It's left over from experiments on exposing some internal metrics, I think during JDK 5. It's code that should probably have been removed a long time ago.

Kirk P raised a concern:

It would be a shame to lose these metrics because many of them have been very
useful over time and some would be even more useful with some modifications.

To which Mandy responded:

What we're referring to is to remove sun.management.Hotspot*, the internal MBeans which are never exposed and registered in the platform MBeanServer.   The internal metrics in HotSpot VM should be retained as they are exposed through other ways like jstat, GC logs, etc.

The email thread seems to have ended here without further action taken.

My interpretation of the above is that we have a consensus that these Hotspot-internal MBeans can be removed. Since I was not part of the initial discussion and some time has passed, I'd like some confirmation that my interpretation is correct.

Would a PR to remove these APIs be welcome?

(This would remove HotspotInternalMBean, HotspotMemoryMBean, HotspotRuntimeMBean, HotspotThreadMBean, with associated implementation, factory methods, tests and probably also some native code in libmanagement. Details can be discussed in a PR)

Cheers,
Eirik.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240320/b2405f7e/attachment-0001.htm>