Why aren't all methods displayed in VisualVM profiler?

Question

I am using VisualVM to see where my application is slow. But it does not show all methods, probably does not show all methods that delays the application.

I have a realtime application (sound processing) and have a time deficiency in few hundreds of microseconds.

Is it possible that VisualVM hides methods which are fast themselves?

UPDATE 1

I found slow method by sampler and guessing. It was toString() method which was called from debug logging which was turned off, but consuming a time.

Settings helped and now I know how to see it: it was depending on Start profiling from option.

Kerbstone

Are you using the sampler or profiler? The sampler, well samples, at a defined time interval. The profiler is more accurate but a lot slower. – Jesus

Debug logging should all be surrounded with if (log.isDebugEnabled()) { or similar to avoid String concatenation and other things taking place in your log calls. – Jesus

See also blogs.oracle.com/nbprofiler/entry/… and blogs.oracle.com/nbprofiler/entry/… to get more information about profiling and how to set profiling roots and instrumentation filter. – Pussyfoot

Answer 1

I don't have it in front of my at the moment, but before you start profiling, there's a settings pane that's hidden by default and lets you enter regexes for filtering out methods. By default, it filters out a lot of the core JDK stuff.

Nutrition

Answer 2

Other than the filters mentioned by Ryan Stewart, here are a couple of additional reasons why methods may not appear in the profiler:

• Sampling profiles are inherently stochastic: a sample of the current stack of all threads is taken every N ms. Some methods which actually executed but which aren't caught in any sample during your run just won't appear. This is generally not too problematic since the very fact they didn't appear in any sample, means that with very high probability these are methods which aren't taking up a large part of your runtime.
• When using instrumentation based sampling in visualvm (called "CPU profiling"), you need to define the entry point for profiled methods (the "Start profiling from" option). I have found this fails for methods in the default package, and also won't pick up time in methods which are current running when the profiler is attached (for the duration of the current invocation - it will get later invocations. This is probably because the instrumented method won't be swapped in until the current invocation finishes.
• Sampling is subject to a potentially serious issue with stack traced based profiling, which is that samples are only taken at safe points in the code. When a trace is requested, each thread is forced to a safe point, then the stack is taken. In some cases you may have a hot spot in your code which does no safe point polling (common for simple loops that the JIT can guarantee terminate after a fixed number of iterations), interleaved with a bit of code that does have a safepoint poll. Your stacks will always show your process in the safe-point code, never in the safe-point free code, even though the latter may be taking the majority of CPU time.

Overripe

Countable loops don't have safepoints, by default, to keep them fast. See for example this bug: bugs.sun.com/bugdatabase/view_bug.do?bug_id=6869327 which is to add a flag to turn this behavior off (but it's on by default). – Overripe

Can you also try to answer this question of mine which was as a result of reading your answer. – Plumlee

Answer 3

I had the same problem with my pet project. I added a package name and the problem is solved. I don't understand why. VisualVM 1.4.1, jdk1.8.0_181 and jdk-10.0.2, Windows 10

Exhaustless