| | The result of the JVM successfully hiding the underlying machine and operating system means that the native information is often useless to Java programmers. Fortunately, each JVM knows how it maps threads, even if this detail is hidden from the application programmers. Java 2 introduced a new API -- the Java Virtual Machine Profiler Interface (JVMPI) -- that allows access to the necessary timing information. | So, here is the good news and the bad news. The bad news is that programmatically querying for CPU usage is impossible using pure Java. There is simply no API for this. A suggested alternative might use Runtime.exec() to determine the JVM's process ID (PID), call an external, platform-specific command like ps, and parse its output for the PID of interest. But, this approach is fragile at best. | This document described how to use the Eclipse Profiler to support the analysis of medium to large bodies of code. A process was described that creates a visual representation of the code as it executes and several techniques were described that allow you to use this captured profiling information to navigate through code rapidly. | This article illustrates how to use JVMTI to create a debugging and profiling tool for Java applications. Such a tool, also called an agent, uses the functionality exposed by the interface to register for notification of events as they occur in the application, and to query and control the application. JVMTI documentation is available here. A JVMTI agent can be useful for debugging and tuning an application. It can illustrate aspects of the application, such as memory allocation, CPU utilization, and lock contention. | Late in 2000, Misha Dmitriev was working at Sun Microsystems Laboratories on what is known as HotSwap functionality of the HotSpot Java Virtual Machine, with the goal of changing code on the fly in running programs. The initial idea was to use HotSwap functionality to "fix-and-continue" code during debugging, without having to stop, recompile, and restart programs. Thus, buggy classes could be replaced on the spot and programmers could immediately determine if a fix worked. Dmitriev also hoped that HotSwap functionality could be used to update running applications in, for example, banking, stock trading, or online ticket reservation systems where downtime costs are high. After some experimentation and deliberation, Sun Labs concluded that, for the time being, such a project was impractical. But what, Dmitriev asked himself, if the same approach could be used to add code to a program in such a way that did not alter its semantics or behavior, but enabled the program to emit useful information about what's happening internally? For example, how much time it takes to execute code, what objects it allocates, and so on. Out of such an observation, the JFluid profiling tool was born, and found its way into the NetBeans IDE, a free and open source IDE that enables programmers to develop cross-platform desktop, web, and mobile/wireless applications. | The Java 2 Platform Standard Edition (J2SE) has always provided a simple command line profiling tool called HPROF for heap and cpu profiling. HPROF is actually a JVM native agent library which is dynamically loaded through a command line option, at JVM startup, and becomes part of the JVM process. By supplying HPROF options at startup, users can request various types of heap and/or cpu profiling features from HPROF. The data generated can be in textual or binary format, and can be used to track down and isolate performance problems involving memory usage and inefficient code. The binary format file from HPROF can be used with tools such as HAT to browse the allocated objects in the heap. | The notion that the JVM somehow takes care of all aspects of resources management have become wide-spread in the Java community, says Gwyn Fisher, CTO of static analysis tool maker Klocwork. While the VM does a good job managing resources for Java objects, it's not designed to take care of all aspects of resource allocation and de-allocation. When developers neglect to think through just what the VM does, and does not do, for their objects, coding errors result: | | Whether you're using System.out.println() or a profiling tool such as hprof or OptimizeIt, code profiling should be an essential component of your software development practice. This article discusses the most common approaches to code profiling and explains their downsides. It provides a list of best-of-breed features you might look for in an ideal profiler and explains why aspect-oriented techniques are well suited to achieving some of those features. It also introduces you to the JDK 5.0 agent interface and walks you through the steps of using it to build your own aspect-oriented profiler. | We began our usual footprint-reduction procedure: set up the test environment, specify a reproducible test, fire up the profiler, run the test, analyze the data, and look for tuning opportunities. Tick follows tock, we do this all the time . . . or so we thought. This time, we got to the "run the test" step, and the profiler fell over. So we tried again. And it died again. We changed the configuration of the profiler to minimize the overhead it needed and tried again. And it died again. There was simply not enough JVM heap space left over to accommodate the profiler for the entire run, let alone generate any useful profiling data. And we were using a classy, commercial profiler, usually very reliable, so we were surprised. | In the second example, you will identify method response times using the WSAD Profiling Tool. In the class below, you are calling a number of methods that each sleep for a predefined number of seconds. In this example, you will repeat Steps 1–7 from the previous section. (The link to the full source code of this class, ProfileTestTwo.java, is located in the zip file at the end of this article.) |
|