Java local Compilation

Measure Java local Compilation Advantages and disadvantages of generating local code from Java source code Original article: http://www.ibm.com/developerworks/cn/java/j-native/

Level: elementary Martyn honeyford, software engineer, ibm uk lab January 18, 2002 When Java native compilation is introduced at the beginning, it seems to be better than JVM, and abandon the platform independence that the Java platform strives. However, even if native compilation becomes more and more popular and there are more and more native compilers on the market, there is still a way to replace Java's portability. Unfortunately, even the maturity of this technology is enough to solve the Java performance problems that currently have headaches for many people. Share your thoughts on this article with the author and other readers in the Forum. Although the Java language has many advantages, there are still several problems that limit the use of key projects. They include execution speed, memory usage, disk usage, and JVM availability. Although the JIT compiler greatly improves the execution speed of the platform and reduces the memory usage, java applications cannot compete with their local competitors (usually C/C ++. To solve these problems, many developers have switched to the Java native compiler, which allows applications to be written in Java and then compiled into the machine executable program. This solution will be at the cost of platform independence, but it can lead to faster execution speed and smaller memory usage, which are critical to many today's applications. To allow you to quickly master the Java native compilation technology, we will first discuss the basics of code compilation, including a brief overview of why many developers are using the Java native compiler to compile their applications. Next, we will use a free software compiler and two different applications (one simple and the other complex) to test the Java native compilation results. These examples and the generated measurement results will serve as first-hand information on how to compare the latest Java native compiler and JVM. Code compilation Basics To understand the content discussed in this article, you should be familiar with the three most common code compilation methods: Use a Java compiler (for example, javac) to compile Java code Compile local code, for example, C/C ++ for a specific hardware/operating system (OS) Platform Use a Java local compiler for a specific hardware/OS platform to compile Java code Using the Java compiler to compile Java code is the simplest. We only need to write the source code in Java and compile the source code into a Java bytecode using the Java compiler. Then we can execute the result on any hardware/OS platform with JVM installed. Its disadvantage is that Java relies on JVM to implement its features of "one-time writing, running anywhere" portability. It should not only install available JVM on any platform that runs Java applications, there must also be a large amount of system resources (memory and disk space) to support JVM. Therefore, many developers still rely on less flexible but more targeted languages, such as C/C ++. Compiling C/C ++ source programs is similar to compiling Java source programs. As long as the code is compiled, we can run it through a compiler and linker for a specific hardware/OS platform. The generated application can be executed only on the target platform, but the JVM does not need to be installed (although it may require some support for shared libraries, depending on the language used ). Almost the simplest applications developed using this method must be customized for each Hardware/OS platform that runs them. The third method tries to combine the advantages of the above two solutions to allow developers to write applications in Java and then compile the cost machine executable programs. After writing the Java code, you can use the Java compiler to generate the Java bytecode, compile the Java bytecode to run it, or directly run the Java code in the Java local compiler. The number of required steps depends on the requirements of the compiler used. The advantage of this method is thatJVM Not Installed. This aims to make Java applications run at a faster speed and greatly reduce the disk space and memory required for running (although it is necessary to provide a support resource library for the Java local compiler ). The compiler's target platform, the Java support level they provide, and the number of system resources they use are all different. In the reference section of this article, you can find a list of currently available native compilers. Test settings Comparing the functional components and performance of each native compiler on the market is far beyond the scope of this article. I use the GNU Compiler Java programming language (gcj) as an example to illustrate the local compilation process and results. Gcj is a compiler developed for the GNU Compiler Collection (GCC). The GNU Compiler set is part of the GNU project. Like all other software from the GNU project, gcj is a free software in a dual sense, so it can be easily obtained (see references ). If you are seriously considering the native compilation path of your product, you should evaluate the compiler as much as possible, maybe you can use the standards set up in this article. My testing system hardware is a PC with a 450 MHz Pentium II processor and 320 MB of memory. The operating system is the recently installed Mandrake 8.1 Linux distribution version. This distribution comes with version 3.0.1 of gcj, which is included in GCC 3.0.1 and provided as part of the 8.1 Mandrake distribution. I have already run two independent applications. One is simple and the other is complicated. To compare the performance of the system and Java platform, I compile the application into a Java bytecode. I used Sun JDK version 1.3.1.02 Linux to compile Java code, and then tested the result class on the following JVM: Kaffe 1.0.6 Sun JVM 1.3.1 _ 02 Ibm jre 1.3.1 For the purpose of this article, I have measured the execution speed, execution memory overhead, and disk space. Test 1: Prime. Java The first test application is simple and consists of a single class of prime. java. This application implements a very basic search prime number algorithm. Listing 1 shows the source code of prime. java. Listing 1. Source Code of prime. Java import java.io.*;class prime{ private static boolean isPrime(long i) { for(long test = 2; test < i; test++) { if(i%test == 0) { return false; } } return true; } public static void main(String[] args) throws IOException { long start_time = System.currentTimeMillis(); long n_loops = 50000; long n_primes = 0; for(long i = 0; i < n_loops; i++) { if(isPrime(i)) { n_primes++; } } long end_time = System.currentTimeMillis(); System.out.println(n_primes + " primes found"); System.out.println("Time taken = " + (end_time - start_time)); }} As you can see, the Code loops from 0 to 50000. During running, it tries to divide each number it encounters by a number smaller than this number to find out whether there is a remainder. (It is undeniable that this is a brute force method for searching prime numbers, but it can meet the needs of this example .) I use the following command to compile the executable program of the cost machine in prime. Java: gcj prime.java -O3 --main=prime -o prime Parameters-O3Parameter: "optimized speed"--mainTell gcj which class contains the main method used when running the application; Parameter-o PrimeName the executable program generated. For a complete set of command line parameters, see the gcj documentation. To compile the Java bytecode test, I used the following command: /usr/java/jdk1.3.1_02/bin/javac -O prime.java Next, for each JVM test, I use the following command to call the code: Local Machine:./prime Kaffe:/usr/bin/java prime Sun JDK:/usr/java/jdk1.3.1_02/bin/java prime IBM JRE:/opt/IBMJava2-13/jre/bin/java prime Test results of prime. Java As described above, I tested the execution speed, memory usage, and disk space usage. The following table describes the results of the first test. Table 1. Prime. Java: execution speed Implementation Time in milliseconds (the average value of three operations-the lower the score, the better) Local Machine 40180 Kaffe 75456 Sun JDK 67315 IBM JRE 18188 Table 2. Prime. Java: memory usage Implementation VM Size (KB) Vm rss (KB) Local Machine 7024 3528 Kaffe 8888 3564 Sun JDK 169560 6636 IBM JRE 81936 6288 Note that the VM Size is equal to the total process image. This includes all the code, data, and shared libraries used by the process, including the pages that have been exchanged. The size of the VM resident set (RSS) is equal to the size of the process (code and data) that actually resides in Ram, including the shared library. This gives an approximate value of how much ram a process uses. Simply put, if a process allocates a large amount of memory, this will be displayed in the VM Size, but will not be displayed in the vm rss until it is actually used (for example, read or write. In fact, Vm RSS is a more important measurement indicator because it reflects the system performance more accurately. Table 3. Prime. Java: disk space usage Implementation Total compilation size (in bytes) Local Machine 22268 Java class 962 Note that the measurements shown in Table 3 do not contain shared libraries and JVM and are measured after executable programs are stripped. Test 2: scimark 2 For the second test, I used a more complex Java application scimark 2 Java benchmark test program. You can get the command line version used in this article for free (see references ). Scimark 2 is a very complex application. It implements many benchmarking programs to accurately evaluate JVM efficiency. I use the following command to compile the cost machine executable program of scimark 2: gcj-3.0.1 -O3 commandline.java Random.java FFT.java SOR.java Stopwatch.java SparseCompRow.java LU.java kernel.java MonteCarlo.java --main=jnt.scimark2.commandline -o scimark Then, I use the following command to compile the application into a Java bytecode: /usr/java/jdk1.3.1_02/bin/javac -O *.java Scimark 2 benchmarking programs can run in two modes: Normal Mode and large mode. The mode you use determines the size of the problem set. I have run the test in these two modes. Use the following command to call the code in Normal Mode: Local Machine:./scimark Kaffe:/usr/bin/java jnt.scimark2.commandline Sun JDK:/usr/java/jdk1.3.1_02/bin/java jnt.scimark2.commandline IBM JRE:/opt/IBMJava2-13/jre/bin/java jnt.scimark2.commandline For a larger problem set, run the following command: Local Machine:./scimark -large Kaffe:/usr/bin/java jnt.scimark2.commandline -large Sun JDK:/usr/java/jdk1.3.1_02/bin/java jnt.scimark2.commandline -large IBM JRE:/opt/IBMJava2-13/jre/bin/java jnt.scimark2.commandline -large Scimark 2 Test Results The following tables show the result of scimark 2 compilation. Note the difference between normal mode and large mode in the result. Table 4. scimark 2, normal mode: execution speed Implementation Compound score (average value of three operations-the higher the score, the better) Local Machine 15.22 Kaffe 7.01 Sun JDK 22.86 IBM JRE 25.29 Table 5. scimark 2. Normal Mode: memory usage Implementation VM Size (KB) Vm rss (KB) Local Machine 9788 5956 Kaffe 8888 4092 Sun JDK 169692 7428 IBM JRE 81964 7408 Table 6. scimark 2, large mode: execution speed Implementation Compound score (average value of three operations-the higher the score, the better) Local Machine 8.78 Kaffe 5.72 Sun JDK 12.04 IBM JRE 15.04 Table 7. scimark 2, large mode: memory usage Implementation VM Size (KB) Vm rss (KB) Local Machine 62888 59072 Kaffe 58056 56988 Sun JDK 169692 64624 IBM JRE 81964 57704 Table 8. scimark 2: disk space used in two modes Implementation Compilation size (bytes) Local Machine 49588 Java class 16318 Again, the measurements in Table 8 do not include shared libraries and JVM and are measured after the executable program is removed. Advantages and disadvantages of local Compilation From the test results, we can see that it is difficult to determine whether the Java local compilation is successful or fails. Some benchmarking programs show that executable programs compiled on the local machine are faster than some JVM versions. Others are the opposite. Similarly, the speed of some operations varies greatly between different JVMs. The execution of the "Working Set" memory test shows that there is no significant difference in memory usage during execution. To further explore this field, you can use different garbage collection solutions for local and JVM testing. The local version is only better than the JVM version in terms of disk space usage, and can be established only when the JVM size is taken into account. Although the class itself is small, the JVM tested is very large (the recursive directory list in the JRE sub-directories of IBM and Sun JVM shows that only JRE occupies 50 MB of disk space ). However, do not forget that many smaller JVMs can be used, although the combination of JVM and a single application is better than that of the local executable program and the gcj Runtime Library libgcj. the combination of SO (less than 3 MB) is much larger, but the size of executable programs in the local version is much larger. Therefore, if a large number of applications are required, the JVM version may be the final winner. In addition to these fuzzy results, using Java native compilation may also cause many potential problems. They are: Lost platform independence: Actually, this is not a big deal. Because the source program is written in Java, you can still choose to generate a Java bytecode version that can be run anywhere, and then use the local compiler on a specific platform as needed. Class Support/compiler Maturity: Some compilers are still relatively immature and may not support all the Java classes required by your application. For example, although gcj supports most Java language structures as defined in Version 1.1NoSupports all Java Class Libraries normally provided together with JVM. Most importantly, it almost does not support AWT, which makes gcj unable to apply to GUI applications. Different compilers support different levels of class libraries; Excelsior jet claims to fully support AWT and swing compilers. Support/complexity: Because this field is relatively new, developers often cannot understand it well. Diagnostic tools may be a little weak on the basis, so it may be more difficult to diagnose problems in locally compiled Java applications (especially when this error is not found in the Java bytecode version ). Conclusion When developing an application, the only practical way to determine whether Java local compilation is suitable for your specific environment is to complete a problem solving cycle. Determine the exact problem that you want to solve using local compilation. Study the available native compilers and then propose some native compilers that may solve the problem. Try to compile your application with all the compilers you selected, and then observe the results. Although Java native compilation technology is still immature and lacks clear results, it is an exciting new field in Java. The best way to use existing options is to use some methods and standards established in this article to personally Study and Test Java native compilation. Although native compilation won't replace JVM (many people think it will replace JVM), it has proved to be the right solution for some applications and environments. Native compilation extends the scope of use of the Java language to some new fields. Java cannot be used in these fields just a few years ago. On the whole, this is only a good thing for the Java language and the Java Community. References For more information, see the original article on the developerworks global site. Please join the Forum on this article. Go to the GNU Compiler for the Java programming language homepage to learn more about the gcj and GNU Compiler collections. Scimark 2.0 is a combination of benchmarking programs used to evaluate the performance of mathematical computing code in scientific and engineering applications. Visit the scimark 2.0 homepage to learn more about this complex application. Learn how to reuse code that is not written in Java from making up for the gap with COM (developerworks, October 2001. When you cannot use a pure Java solution in your application, you can still effectively debug the Java/C hybrid. Matthew white explains how to do this in "Debug Integrated Java and C/C ++ Code" (developerworks, November 2001. For more java references, see the developerworks Java technology area. Optional Java local Compiler Gcj Bullettrain Excelsior Jet Jove Towerj Visual cafe Visualage for Java Fastj About the author Martyn honeyford graduated from the University of Nottingham in 1996 and obtained a bachelor's degree in computer science. Since then, he has become a software engineer at the ibm uk lab in hursley, England. He is currently a developer in the WebSphere MQ everyplace development team. When he is not at work, he often plays electric guitar (which is very bad) or crazy video games. You can contact Martyn through a martynh@uk.ibm.com.