Java performance in 64-bit system environments

If you want to buy a car and your primary goal is performance or, more specifically, primitive power, then the answer is clear if you choose between a 4-cylinder engine and an 8-cylinder engine, because the larger the value, the better. Generally, when we look at the computer configuration list or product promotion, the 64-Bit performance is also superior to the 32-bit, And the quad-core is also better than the dual-core.

However, the more simple things in the world of Datong, the better it is, the more difficult it is to move to the computer field. When processing multiple CPUs, you will think that the processing units that are multiple cores are very useful, but if you work only on a single thread, what you need to do is to let the other core side rest.

The comparison between 32-bit and 64-bit is more subtle. The x86-64 architecture not only increases the number of registers based on the X86 architecture, but also increases the number of registers. Basically, this will bring better performance (because more registers allow the compiler to create better machine code ). However, unfortunately, so far, the performance of Java has been reduced from 32 to 64-bit.

Speaking of Java performance, two key aspects of runtime are: JIT and GC. JIT is used to execute code as quickly as possible. GC is used to extract as little time as possible from Code Execution (while managing storage. Therefore, the performance of Java is to allow JIT (with the help of more memory) to generate more ideal code and reduce the time for GC to manage storage (the larger the pointer, the more difficult)

Java 9 was initially designed as a 32-bit system, which affects some of our early decisions on code base. A few years ago, I spent a lot of time trying to run our Smalltalk VM on a 64-bit PowerPC system. The conclusion is: the most direct solution is to double all data structures (objects) to process 64-bit pointers. With the development of Java 9 (about 2001), the first 64-bit system we got was a DEC Alpha, So we adopted this most direct "bigger" solution, A common code base supports both 32-bit and 64-bit.

The 64-bit CPU has a wider data bus, but the same 64-bit CPU can run 32-bit code and has the same wide data bus. Let's look back at our 64-bit solution, which doubles the data structure, but the effect is not as good as 32-bit on the same hardware, that is, 64-bit is less than 32-bit. This problem is neither Java 9 nor Java exclusive, because all 64-bit data needs to be extended. Java only highlights this issue, because Java programming is usually related to creating and manipulating objects (also called data structures.

The solution to the performance problem is to intelligently process the data structure, which is exactly what we did in Java 6 JDK using the compressed references feature. We can be clever and won't be caught, because users (Java programmers) are not clear about the deeper performance of Java objects.

The solution to the compromise is to store less information in the object and limit the storage that can be used by JVM. This is a pretty good solution, because the size of computer storage is far smaller than the limit address range of 64-bit. We only use 32 bits to store pointers, and make full use of aligned objects to get some space (pointers <3 ). Therefore, using compressed references-xcompressedrefs, the IBM Java 6 JDK can address a heap of up to 32 GB.

Not only do we use this technique. Oracle/BEA has-xxcompressedrefs and Sun has-XX: + usecompressedoops. Of course, the methods of different vendors vary slightly in terms of limits and support levels. You may disagree, but when a user runs to a 32-bit operating system's stack limit, they want a 64-bit System (without compromising performance ).