Native profiling tools are those that profile the JVM itself. This allows visibility into what
the JVM is doing, and if an application includes its own native libraries, it allows visibility
into that code as well. Any native profiling tool can be used to profile the C code of the JVM
(and of any native libraries), but some native-based tools can profile both the Java and
C/C++ code of an application.
Figure 3-6 shows the now-familiar profile from starting GlassFish in the Oracle Solaris Stu-
dio analyzer tool, which is a native profiler that understands both Java and C/C++ code. (Al-
though it has Solaris in its name, this tool works on Linux systems as well; in fact, these im-
ages are from profiling on a Linux OS. However, the kernel architecture of Solaris allows the
tool to provide even more application visibility when run on Solaris.)
Figure 3-6. A native profiler
The first difference to note here is that there is a total of 25.1 seconds of CPU time recorded
by the application, and 20 seconds of that is in JVM-System . That is the code attributable to
the JVM itself: the JVM's compiler threads and GC threads (plus a few other ancillary
threads). We can drill into that further; in this case, we'd see that virtually all of that time is
spent by the compiler (as is expected during startup, when there is a lot of code to compile).
A very small amount of time is spent by the GC threads in this example.
Unless the goal is to hack on the JVM itself, that native visibility is enough, though if we
wanted, we could look into the actual JVM functions and go optimize them. But the key
piece of information from this tool—one that isn't available from a Java-based tool—is the
amount of time the application is spending in GC. In Java profiling tools, the impact of the
GC threads is nowhere to be found. (Unless the test is run on a machine which is CPU-
bound, the large amount of time in the compiler thread will not matter: that thread will con-