JDK-8134615 : Some MXBeans rely on UsePerfData being enabled
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-08-27
  • Updated: 2023-01-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8246020 - -XX:+UsePerfData is enabled by default and slows down VM bootstrap by 6%
Description
A lot of the internal MXBeans get the data they need from the equivalent perf counters (which is good given that the data is consistent across both APIs!). However, the perf counters used by the runtime service (safepoint stats and a few other things) are only created if UsePerfData is enabled and any code that relies on said counters gets a value of -1 if UsePerfData is disabled.

Comparing the code in the thread and runtime services, the former always creates the counters (and they are malloced if UsePerfData is disabled) whereas the latter creates the counters conditionally. The patch to fix this and bring the runtime service code in line with the rest is quite small and straightforward (remove the 'if (UsePerfData) ...' conditions).

Is there any interest in this patch? Also: Is there maybe a good reason why the runtime service is been implemented the way it is?
Comments
Actually, classLoadingService.cpp is using the same trick to setup the counters necessary for the corresponding ClassLoading MXBean. IMO, we should either remove this unconditional creation of the perf counters for the needs of java.lang.management (and update the spec to state that you won't be able to get certain data if UsePerfData has been disabled) or update the runtimeService.cpp to provide a consistent experience.
17-09-2015
Are we willing to change the definition of UsePerfData to say that it optionally disables creation of the counters? I would not accept this patch unless I'm willing to accept that redefinition. That's perhaps not much of an answer but is as generous as I'm feeling right now.
15-09-2015
I would guess that Tony wants to disable UsePerfData due to JDK-8076103
14-09-2015
I have to ask why you think there is a need to support these internal counters when UsePerfData has been disabled. Given it is enabled by default (except on SE Embedded) one has to think that if it has been turned off then the user had a reason to do so - in which case bypassing that off-switch may negate the objective of the user. This is unfortunately one of those changes for which any impact is "out there" and can not readily be determined.
04-09-2015
Looking at the history the UsePerfData flag was added to control the jvmstat functionality that was added in 1.4.1 - and due to bugs it was off by default so all perfcounter usage was guarded. In 1.4.2 UsePerfData was enabled by default. In Java 5 we have the new monitoring and management APIs which used the Perf* types for its counters/variables. Those in ThreadService needed to be always-on // These counters are for java.lang.management API support. // They are created even if -XX:-UsePerfData is set and in // that case, they will be allocated on C heap. as indicated by their non-optionality in the specification: http://docs.oracle.com/javase/8/docs/api/java/lang/management/ThreadMXBean.html While those in RuntimeService are only used by the internal, undocumented HotspotRuntimeMBean - though it seems oblivious to the potential that these counters may be disabled by -UsePerfData.
04-09-2015
David, attached the diff (TonyMXBeans - sorry I should have named it more appropriately; I just copied the MQ patch file). _sync_time_ticks _total_safepoints _safepoint_time_ticks all three are accessed from VMManagementImpl and from HotspotRuntimeMBean. _application_time_ticks is only accessed from VMManagementImpl. The above return -1 with -UsePerfData and without the patch, the right value with -UsePerfData and the patch. I didn't look deep into how the two constants ("jvmVersion" and "jvmCapabilities") are accessed (I assume only with jvmstat?).
31-08-2015
David, thanks for the reply. I'll attach a diff on Monday (unfortunately I ended up being busy with a bunch of other things today).
28-08-2015
Tony, can you attach the patch so that we can quickly see what objects are involved? Not sure what the history is on this.
27-08-2015