Artiom Gourevitch

The aim of this article is to learn how to dynamically trace/observe running Java applications (JDK 6+) using BTrace without changing the code and configuration params of the applications. What is BTrace? BTrace is an open source project that was started in 2007 and was originally owned by two people – A.Sundararajan and K. Balasubramanian. It gained fame thanks to Java One 2008 conference. BTrace helps us to pinpoint complicated code problems in the application. The problems that can be solved using BTrace include code bugs, unpredictable flows, concurrency problems and performance problems that happen under specific and usually hard to reproduce circumstances. BTrace dynamically (without restarting application) instruments (changes) bytecode of an application in the way that programmer defines. The goal of the instrumentation is to see what happens in a specific area of the code. If used beyond this scope it may harm applications' flow and therefore is forbidden by a validator. For example let's try to solve following problem – an important file gets deleted occasionally once a day. We want to find the code that does this. Therefore we would like to change "delete" method of java.io.File and print a stack trace of the calling thread if the file name fits. With BTrace we can do this by writing a short and straightforward Java code. The following schema displays principles of BTrace work. In Target JVM there is a dynamically inserted BTrace agent (using attach API). BTrace client (either BTrace Command Line or Visual VM with BTrace plugin) sends commands to the agent and gets responses. BTrace agent instruments classes that are being loaded into Target JVM and reloads classes that have already been loaded. Writing a Tracing script Writing BTrace scripts is pretty simple and straightforward and has concepts similar to Aspect Oriented Programming concepts. import com.sun.btrace.annotations.*; import com.sun.btrace.BTraceUtils; @BTrace public class HelloWorld { @OnMethod(clazz="java.io.File",method="") public static void onNewFileCreated(String fileName) { BTraceUtils.println("New file is being created"); BTraceUtils.println(fileName); } Each BTrace script consists of Probes (pointcuts in Aspects slang) and Actions (advices). A probe defines when the instrumentation should be executed. Action defines the instrumentation. Probe can consist of the following: Method entry/exit Line number Field updated/accessed Method call/return (within specified method(s)) Exception throw (before) Synchronization entry/exit Timer Constructor entry Abilities and limitations of BTrace Abilities Dynamically connect to any java6 + application and run any(*) code Limitations Must run with the same user as the traced application is running with - due to security concerns Supports Hotspot JVM only Is compiled separately from the target application – is not familiar with application classes May crush target application - I ran BTrace on our longevity setup which was heavily loaded with many Tracing scripts. Target application didn't crush even once. Advanced BTrace BTrace community consists de facto of a single developer that works regularly on the project. Therefore don't expect too much improvement and many new features in the next releases. (This is a good opportunity to contribute to the project as each developer will enhance the development significantly). Documentation of the project should be significantly improved - I found myself guessing many times while integrating this framework into the existing frameworks at my job. BTrace forum is a good way to get answers about the framework. In order to understand how the magic of BTrace works, knowledge in three fields is required - "Java Agents Development", "Bytecode manipulation in java" and "Java attach api". I may write about some of these fields in the future. References Check out my blog http://www.parleys.com/#st=5&id=1618&sl=1 http://kenai.com/projects/btrace

What is JIT Compiler? The Just In Time Compiler (JIT) concept and more generally adaptive optimization is well known concept in many languages besides Java (.Net, Lua, JRuby). In order to explain what is JIT Compiler I want to start with a definition of compiler concept. According to wikipedia compiler is "a computer program that transforms the source language into another computer language (the target language)". We are all familiar with static java compiler (javac) that compiles human readable .java files to a byte code that can be interpreted by JVM - .class files. Then what does JIT compile? The answer will given a moment later after explanation of what is "Just in Time". According to most researches, 80% of execution time is spent in executing 20% of code. That would be great if there was a way to determine those 20% of code and to optimize them. That's exactly what JIT does - during runtime it gathers statistics, finds the "hot" code compiles it from JVM interpreted bytecode (that is stored in .class files) to a native code that is executed directly by Operating System and heavily optimizes it. Smallest compilation unit is single method. Compilation and statistics gathering is done in parallel to program execution by special threads. During statistics gathering the compiler makes hypotheses about code function and as the time passes tries to prove or to disprove them. If the hypothesis is dis-proven the code is deoptimized and recompiled again. The name "Hotspot" of Sun (Oracle) JVM is chosen because of the ability of this Virtual Machine to find "hot" spots in code. What optimizations does JIT? Let's look closely at more optimizations done by JIT. Inline methods - instead of calling method on an instance of the object it copies the method to caller code. The hot methods should be located as close to the caller as possible to prevent any overhead. Eliminate locks if monitor is not reachable from other threads Replace interface with direct method calls for method implemented only once to eliminate calling of virtual functions overhead Join adjacent synchronized blocks on the same object Eliminate dead code Drop memory write for non-volatile variables Remove prechecking NullPointerException and IndexOutOfBoundsException Et cetera When the Java VM invokes a Java method, it uses an invoker method as specified in the method block of the loaded class object. The Java VM has several invoker methods, for example, a different invoker is used if the method is synchronized or if it is a native method. The JIT compiler uses its own invoker. Sun production releases check the method access bit for value ACC_MACHINE_COMPILED to notify the interpreter that the code for this method has already been compiled and stored in the loaded class. JIT compiler compiles the method block into native code for this method and stores that in the code block for that method. Once the code has been compiled the ACC_MACHINE_COMPILED bit, which is used on the Sun platform, is set.How do we know what JIT is doing in our program and how can it be controlled? First of all to disable JIT Djava.compiler=NONE parameter can be used. There are 2 types of JIT compilers in Hotspot - one is used for client program and one for server (-server option in VM parameters). Program, running on server enjoys usually from more resources than program running on client and to server program top throughput is usually more important. Hence JIT in server is more resource consuming and gathering statistics takes more time to make the statistics more accurate. For client program gathering statics for a method lasts 1500 method calls, for server 15000. These default values can be changed by -XX:CompileThreshold=XXX VM parameter. In order to find out whether default value is good for you try enabling "XX:+PrintCompilation" and "-XX:-CITime" parameters that print JIT statistics and time CPU spent by JIT. Benchmarks Most of the benchmarks show that JITed code runs 10 to 20 times faster than interpreted code. There are many benchmarks done. Below given result graphs of two of them: Its worth to mention that programs that run in JIT mode, but are still in "learning mode" run much slower than non JITed programs. Drawbacks of JIT JIT Increases level of unpredictability and complexity in Java program. It adds another layer that developers don't really understand. Example of possible bugs - 'happens before relations" in concurrency. JIT can easily reorder code if the change is safe for a program running in single thread. To solve this problem developers make hints to JIT using "synchronized" word or explicit locking. Increases non heap memory footprint - JITed code is stored in "Code Cache" generation. Advanced JIT JIT and garbage collection. For GC to occur program must reach safe points. For this purpose JIT injects yieldpoints at regular intervals in native code. In addition to scanning of stack to find root references, registers must be scanned as they may hold objects created by JIT Comments are appresiated. The article can be found also at: artiomg.blogspot.com/2011/10/just-in-time-compiler-jit-in-hotspot.html