Frequently Asked Questions

1. Why use StackProbe instead of one of the numerous free open-source Java profilers?
2. How much does StackProbe affect performance of the profiled application?
3. How does sampling work?
4. What is expected sampling error?
5. So sampling profilers are inaccurate. Well, I better use an instrumenting profiler...
6. Ok, I try to run it, but it displays a message about missing JDK.
7. I have installed JDK 6, but it still doesn't start.
8. Can I profile applications running on the older versions of JVM?
9. How to make StackProbe look like on the screenshots?
10. How can I make StackProbe use less memory?
11. Why does StackProbe report values higher than 100% for some methods?

1. Why use StackProbe instead of one of the numerous free open-source Java profilers?

   Because open-source Java profilers would not solve the performance problems of your application as quickly as StackProbe would. Most of them lack basic features like context profiling or cause large overheads and introduce fake bottlenecks to your application. Short comparison of StackProbe to some commonly used open-source profilers:

   	StackProbe	NetBeans profiler	VisualVM profiler	Profiler4J	hprof
   Profiling technique	Sampling	Instrumen- tation	Instrumen- tation	Instrumen- tation	Sampling or Instrumentation
   Overhead	Low, user controllable	High	High	High	Low
   Interface	GUI	GUI	GUI	GUI	Command line
   Initialization	Immediate	Slow	Slow	Slow	Immediate
   Flat profile	Yes	Yes	Yes	No	Yes
   Hierarchical profile	Yes	Partial	No	Partial	No
   Runnable/Waiting/Blocked timings	Yes	No	No	No	No
   Profile comparison	Yes	No	No	No	No
   Merging multiple profiling sessions	Yes	No	No	No	No

2. How much does StackProbe affect performance of the profiled application?

   It depends of its settings and hardware. Typically the profiled application will run at 60% to 99% of its normal speed. If the profiled application does not use all of the processors/cores and some CPU power is left to the profiler, you probably won't notice any slowdown at all. You can make the overhead even smaller by running StackProbe on a separate computer. The extremely low overhead is possible thanks to sampling technique used by StackProbe, which allows it to obtain profiles without the need of changing the profiled code.

3. How does sampling work?

   StackProbe periodically asks the JVM for the list of stacktraces for all active threads. These lists are called samples. The more time the profiled application spends in a method, the more often the method will occur in the samples. The main advantage of this technique is that, though it even introduces some slight overhead, this overhead is distributed equally among all the methods of the profiled application, so there is no risk of introducing false bottlenecks or other systematic inaccuracy.

4. What is expected sampling error?

   Sampling error is inacurracy in the obtained profile caused by a finite number of samples. Sampling error is large, when there are few samples, and decreases while more samples are gathered. Usually gathering 100 samples is enough to get the location of bottlenecks and 500 samples can give much information for applications with no obvious bottlenecks.

   Sampling error is measured in percentage points (p.p.). Sampling error of 3 p.p. means that a method reported by the profiler to be executed 50% of the time, may really use 47% to 53% of the time (for statistical purists: with a probability of 0.95).

5. So sampling profilers are inaccurate. Well, I better use an instrumenting profiler...

   Instrumenting profilers are inaccurate too, but in a much worse way than sampling ones.

   First, each invocations of a given method never take the same amount of time (because the OS is doing something in the middle, or GC kicks in, or...), and you have to average more invocations to deal with the error in the same way as when using a sampling profiler.

   Second, and much worse, the profiler introduces systematic error you cannot decrease by any means. Instrumentation not only adds some code to your application, but also affects optimizations applied by the HotSpot compiler. Thus, the originally small inlined method may end up being standard method performing slow system calls to System.nanoTime(). Usually shorter methods are affected more than longer ones, so the instrumenting profiler effectively changes the profile of the application. And believe me, fighting false bottlenecks is not the thing you would really like to do, would you?

6. Ok, I try to run it, but it displays a message about missing JDK.

   So you need to install full JDK on your computer instead of JRE. The version 6 is required, but we recommend you installing at least JDK 6 update 10 to get a nice Nimbus look&feel as in the screenshots. You can get it from here.

7. I have installed JDK 6, but it still doesn't start.

   It means you have probably both public JRE and JDK installed on the same computer, and the java on your system is configured to use the JRE by default. There are at least 3 solutions to this problem:

   • Uninstall both JRE and JDK and then install only JDK (to make shortcuts work).

   • Run StackProbe with a command line statement (you can make a .bat or .sh file for it, if you wish):

     path_to_the_jdk/jre/bin/java -jar stackprobe.jar

   • Configure correct JDK version for the JNLP in the Java Control Panel and launch StackProbe from this website by clicking red "Run Now!" icon.

8. Can I profile applications running on the older versions of JVM?

   Yes, for JVM 5 and newer. Unfortunately JMX in older versions of JVM doesn't support ThreadMXBean required for running StackProbe.

9. How to make StackProbe look like on the screenshots?

   Install JDK 6 update 10 or newer. StackProbe will automatically detect Nimbus is available.

10. How can I make StackProbe use less memory?

    Yes - there are two methods, which can be even applied together:

    • Open configuration dialog and specify some thread/method filters. StackProbe doesn't use memory for profiles of threads and methods that are filtered out. As a side effect, the profiling overhead will decrease.
    • Decrease the maximum call tree depth. This can be set also in the configuration dialog.

11. Why does StackProbe report values higher than 100% for some methods?

    This is not a bug, this is a feature! In multithreaded applications some methods are reentrant and can be executed by more than one thread at once. The timings reported by StackProbe are the sum of timings of each individual thread calling that method. Thus, two threads simultaneously executing the same method for the whole time, would yield 200% activity. The proportions of time spent by each thread in the method is listed in the thread tree in the upper right corner of the window.