Monitoring Java Safepoint Time in JDK16+

[David Holmes]

On 17/06/2021 11:44 pm, Carter Kozak wrote:
> On 17/06/2021 3:15 pm, Alan Bateman wrote:
>  > On 17/06/2021 02:39, David Holmes wrote:
>  >> In what way does this no longer work? We have a test in
>  >> jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java that
>  >> uses this API and doesn't seem to need to do anything to allow 
> access. ??
>  > That test is compiled/run with `--add-exports
>  > java.management/sun.management=ALL-UNNAMED 
> <http://java.management/sun.management=ALL-UNNAMED>`, just not immediately
>  > obvious because the TEST.properties with the config for jtreg is in the
>  > parent directory (it applies to tests in that directory and all
>  > sub-directories). Carter would have need the equivalent to compile with
>  > JDK 9+ and to run with JDK 16+.
> 
> Thanks for the clarification! The trouble is that I maintain a 
> microservice framework/library which produces metrics, however I don't 
> have access to provide java arguments in most cases. I'd prefer to avoid 
> requiring additional manual action from my users when they upgrade to 
> the next java LTS, especially given we don't want to get into the habit 
> of opening additional modules after the fact. This is useful information 
> as a break-glass measure, and something I can work with, but I'd like to 
> work toward an end state in which there's an exposed public API to 
> capture safepoint metrics. The JFR event stream may be that mechanism, 
> although I'm not sure the overhead/tradeoffs make sense as a replacement 
> given we're already aggregating safepoint time elsewhere in memory.

I must admit I'm a bit confused about these implementation-specific 
MBeans. They are implementation-specific, so no part of the primary 
java.management namespace, but they are provided so that they can be 
used - so shutting them behind the modular doors (so to speak) really 
doesn't make much sense to me.

David
-----

> Thanks,
> Carter
> 
>