Why does jProfiler show Unsafe.park/unpark as using CPU cycles?

Question

We're running a service using quite a lot of ExecutorServices.

When profiling the service using jProfiler 7.1 (sampling, Runnable), we can see that sun.misc.Unsafe.park + unpark is currently the calls using most of the CPU time in the hotspot.

https://i.sstatic.net/wT2Cj.jpg

This is puzzling.

Park and unpark should be blocking, hence not use any CPU cycles (or at least a low amount). Is this some sort of bug from the jprofiler (i.e. not detecting it, because it's in the sun.misc package?) or is there actually something wrong in our use of the ExecutorService framework?

Genius

Is it possible that you have a debugger attached that might be pausing some threads? – Celestine

No, no debugger attached. Also, as the trace suggests, it's simply in the getTask part of the ExecutorService that most "time" is spent – Genius

Our hope is, that this is simply a "bug" in jProfiler. I have a hard time believing that the Worker thread in Executor service is actually burning cycles while waiting for tasks. – Genius

@RasmusFuglsang I want to say it is more likely a bug in jProfiler. For instance, I know hprof takes the a start time right before entering a method and one after. It's possible jprofiler doesn't take the suspension of the thread into consideration and counts it as time spent – Como

@RasmusFuglsang JProfiler support here, it looks indeed like a bug. This is certainly not the normal behavior and it does not happen in our test cases and the JVMs we test with. Unsafe.park() and Unsafe.unpark() are special methods and are handled specially by us. Does this happen with the "JDBC sample" session as well (it uses thread pools as well)? Please write to [email protected] with more details about the JVM version that you are using and the platform that the profiled JVM is running on. – Haemophilia

Answer 1

This is fixed in JProfiler 7.1.1. It could happen when you disconnected and reconnected to a profiled JVM.

Haemophilia