and monitor-wait events for this example will be high; those can be ignored (and in fact they
are often a good candidate to filter out). What about the other events?
Over the 66-second period, multiple threads in the application spent 40 seconds writing to
sockets. That's not an unreasonable number for an application server running across four
CPUs (i.e., with 264 seconds of available time), but it does indicate that performance could
Similarly, multiple threads spent 143 seconds reading from sockets. That number sounds
worse, and it is worthwhile to look at the traces involved with those events, but it turns out
that there are several threads that use blocking I/O to read administrative requests that are ex-
pected to arrive periodically. In between those requests—for long periods of time—the
threads sit blocked on the read() method. So the read time here turns out to be acceptable:
just as when using a profiler, it is up to you to determine whether a lot of threads blocked in
I/O is expected, or if it indicates a performance issue.
That leaves the monitor-blocked events. As discussed in Chapter 9 , contention for locks goes
through two levels: first the thread spins waiting for the lock, and then it uses (in a process
called lock inflation) some CPU- and OS-specific code to wait for the lock. A standard pro-
filer can give hints about that situation, since the spinning time is included in the CPU time
charged to a method. A native profiler can give some information about the locks subject to
inflation, but that can be hit-or-miss (e.g., the Oracle Studio analyzer does a very good job of
that on Solaris, but Linux lacks the operating system hooks necessary to provide the same in-
formation). The JVM, though, can provide all this data directly to JFR.
An example of using lock visibility is shown in Chapter 9 , but the general takeaway about
JFR events is that, since they come directly from the JVM, they offer a level of visibility into
an application that no other tool can provide. In Java 7u40, there are 77 event types that can
be monitored with JFR. The exact number and types of events will vary slightly depending
on release, but here are some of the more useful ones.
The list of events that follows displays two bullet points for each event type. Events can col-
lect basic information that can be collected with other tools like jconsole and jcmd ; that
kind of information is described in the first bullet. The second bullet describes information
the event provides that is difficult to obtain outside of JFR.
▪ Number of classes loaded and unloaded
▪ Which classloader loaded the class; time required to load an individual class