VisualVM reports "CPU usage: <unknown>"

[swpalmer]

Describe the bug The monitoring tab shows "CPU usage: ", while other features are working as expected.

To Reproduce Steps to reproduce the behavior:

1. Run application with Zulu build of OpenJDK java.vm.specification.version=17 java.vm.vendor=Azul Systems, Inc. java.vm.version=17+35-LTS javafx.runtime.version=17.0.0+100 javafx.version=17.0.0

2. Run VisualVM with Zulu JDK 19 System Info: Product Version = VisualVM 2.1.5 Operating System = Windows 11 version 10.0 running on amd64 Java; VM; Vendor = 19.0.1; OpenJDK 64-Bit Server VM 19.0.1+10; Azul Systems, Inc. Runtime = OpenJDK Runtime Environment 19.0.1+10 Java Home = C:\Program Files\Zulu\zulu-19

3. Double click the application in the Appications list to connect

4. Go to the Monitor tab

5. Notice all 4 graphs are active, but CPU usage for the application says , GC activity says 0.0%

Expected behavior CPU usage should be visible.

VisualVM log cpu_unknown_logfile.txt

Screenshots

Desktop (please complete the following information):

• OS: Windows 11 - Microsoft Windows [Version 10.0.22621.963]
• JDK version openjdk 19.0.1 2022-10-18 OpenJDK Runtime Environment Zulu19.30+11-CA (build 19.0.1+10) OpenJDK 64-Bit Server VM Zulu19.30+11-CA (build 19.0.1+10, mixed mode, sharing)
• Version 2.1.5

Additional context Application is running a JavaFX GUI and makes extensive use of JNI. Runtime of monitored application is: openjdk 17 2021-09-14 LTS OpenJDK Runtime Environment Zulu17.28+13-CA (build 17+35-LTS) OpenJDK 64-Bit Server VM Zulu17.28+13-CA (build 17+35-LTS, mixed mode)

It was generated with jlink and includes the following modules: java.base@17 java.compiler@17 java.datatransfer@17 java.desktop@17 java.instrument@17 java.logging@17 java.management@17 java.management.rmi@17 java.naming@17 java.net.http@17 java.prefs@17 java.rmi@17 java.scripting@17 java.se@17 java.security.jgss@17 java.security.sasl@17 java.smartcardio@17 java.sql@17 java.sql.rowset@17 java.transaction.xa@17 java.xml@17 java.xml.crypto@17 javafx.base@17 javafx.controls@17 javafx.fxml@17 javafx.graphics@17 javafx.media@17 javafx.swing@17 javafx.web@17 jdk.accessibility@17 jdk.attach@17 jdk.crypto.cryptoki@17 jdk.crypto.ec@17 jdk.crypto.mscapi@17 jdk.hotspot.agent@17 jdk.httpserver@17 jdk.internal.jvmstat@17 jdk.jdwp.agent@17 jdk.jsobject@17 jdk.management.agent@17 jdk.unsupported@17 jdk.unsupported.desktop@17 jdk.xml.dom@17

[thurka]

It was generated with jlink and includes the following modules

Aha, this is new to me. This can cause your problem. Can you try with stock Zulu17.28+13-CA? I gues that you are missing some modules.

[thurka]

You can also install VisualVM-MBeans plugin and see if you have OperatingSystem MBeans with ProcessCpuTime attribute. See the screenshot below:

[thurka]

I guess that the missing module is jdk.management.

[swpalmer]

Another system where CPU usage is reported has the following modules: com.azul.crs.client@17.0.5 com.azul.tooling@17.0.5 java.base@17.0.5 java.compiler@17.0.5 java.datatransfer@17.0.5 java.desktop@17.0.5 java.instrument@17.0.5 java.logging@17.0.5 java.management@17.0.5 java.management.rmi@17.0.5 java.naming@17.0.5 java.net.http@17.0.5 java.prefs@17.0.5 java.rmi@17.0.5 java.scripting@17.0.5 java.se@17.0.5 java.security.jgss@17.0.5 java.security.sasl@17.0.5 java.smartcardio@17.0.5 java.sql@17.0.5 java.sql.rowset@17.0.5 java.transaction.xa@17.0.5 java.xml@17.0.5 java.xml.crypto@17.0.5 javafx.base@17.0.5 javafx.controls@17.0.5 javafx.fxml@17.0.5 javafx.graphics@17.0.5 javafx.media@17.0.5 javafx.swing@17.0.5 javafx.web@17.0.5 jdk.accessibility@17.0.5 jdk.attach@17.0.5 jdk.crypto.cryptoki@17.0.5 jdk.crypto.ec@17.0.5 jdk.crypto.mscapi@17.0.5 jdk.hotspot.agent@17.0.5 jdk.httpserver@17.0.5 jdk.internal.jvmstat@17.0.5 jdk.jdwp.agent@17.0.5 jdk.jfr@17.0.5 jdk.jsobject@17.0.5 jdk.management.agent@17.0.5 jdk.unsupported@17.0.5 jdk.unsupported.desktop@17.0.5 jdk.xml.dom@17.0.5

There is still no jdk.management, just jdk.management.agent, which is present on both. That leaves the following modules the only difference: com.azul.crs.client@17.0.5 com.azul.tooling@17.0.5 jdk.jfr@17.0.5

[thurka]

I bet some of thise extra modules has dependecy on jdk.management. If you take a heap dump, VisualVM can tell you in heap dump "Summary", which modules are present in the heap dump (GH-275).

[swpalmer]

If they did have such a dependency, then the module would end up in the JDK and be listed, would it not?

[swpalmer]

Nevermind... my information about the "working" system was wrong. It was not running on JDK 17! (It was supposed to be, but I made a mistake somewhere)

[swpalmer]

That was the issue. Adding the jdk.management module was all that was needed. Thank you!