JavaOne: Java Merge
As you all know, yesterday passed the first day of the long-awaited JavaOne. It is worth noting that this event is being held in Moscow for the first time, to which I am extremely happy. There were many different interesting and useful reports, but I liked the section about the merger of HotSpot and JRockit all the more. Firstly, I knew little about JRocket, secondly, I heard this news for the first time, and the report contained quite a lot of details. The presentations will be posted on the official website of the event only after two weeks, so I decided to retell what I heard in free performance. Especially from the comments to one of my previous posts, I understand that there are not very many people familiar with JRockit in Habré, so I think the topic will be of interest to the habrasoobshchestvo.
This decision is due to cost reduction. Oracle noticed that customer requirements for both JVMs are in general the same, and users want to see the same things in both products. To achieve these goals, the developers of both JVMs independently come to implement the same ideas, for example, EscapeAnalysis and the predictable garbage collector (Garbage First from HotSpot and Deterministic GC from JRockit). So why ask duplicate work?
Each solution has its strengths and weaknesses. At the moment, HotSpot's strengths can be considered a wide area of use, a large customer base, high fault tolerance and performance. JRockit also stands out with its optimization for the stack of Oracle products on Linux and Windows, the availability of a soft real-time solution and a version to run on bare hardware without an operating system (of course, on a special hardware, and not arbitrary).
Surprisingly, there were long discussions of what kind of JVM to take as a base. As a result, it was decided in favor of HotSpot, but the arguments were not technical. The reasons were the existence of OpenJDK, made on the basis of HotSpot, the number of engineers working on HotSpot (engineers working on JRockit will implement the features of their offspring in the new common JDK), licenses issued by IBM, HP and other companies for modifying HotSpot. There is also sad news - not all merzh will fall into OpenJDK. The first results of the merge can already be seen in Java 7. For example, there it is already planned to translate PermGen to C-heap. To complete all the work on the merger is planned for two years.
')
What are the requirements for a modern virtual machine? The first is scalability. A virtual machine should work on a large range of machines, from cell phones to mainframes, allow working with large amounts of memory, work effectively on a large number of hardware streams (~ 10,000), and take into account the topology of memory. The second is speed. The virtual machine must be high-performance, predictable (JIT, GC), start quickly and have a small overhead (footprint).
NUMA allocation. Allows you to create an object in memory closer to the processor on which the work occurs. Since the probability that the thread created the object and will work with it more, then the profit on the face. Various tests showed an increase in performance from 25 to 300%.
Optimization of work with strings. It's no secret that various applications work a lot with strings, if not for pram, then various library methods still create them. For example, such optimizations were made such as string merging (-XX: + OptimizeStringConcat), string copying, string compression (-XX: + UseCompressedStrings, available only in 6u21p, then disabled), which allows storing characters in an array of bytes, if possible, and same string caching (xx: + usestringcache).
Compressed pointers. Enabled automatically if the JVM decides that it will give a profit. But you can enable it with the -XX option: + UseCompressedOops. This compression occurs due to shifts, which help to reduce the space lost during alignment. With this option, you can work with memory up to 32 GB. They say that it works even faster than the 32-bit JVM.
Garbage Firts. Starting with version 6u14, you can enable the -XX option: + UseG1GC. This collector is already working very stably, but not yet finished, as there are minor performance problems (spikes occur).
Step compilation. In order to have a quick startup, the JVM is launched with the client JIT compiler, after some time the compiler is changed to the server compiler.
And of course, EscapeAnalysis has already been pushed so many times and more efficient copying of arrays.
On the front of JRockit, reliability and predictability can be distinguished. Using a consistent thread termination model. Powerful JIT compiler. API for testing plus a set of well covering tests (HotSpot is not enough for how much I know). Sampling compiler.
JRockit has a very powerful toolkit for support and debugging. You can highlight the presence of the so-called "flight recorder", which records everything that happened with the JVM and decoding which will help to understand when a non-standard situation occurs. To monitor the current state there is such a tool as Mission Control, which looks noticeably more powerful than the Visual VM for HotSpot. It is also possible to track native memory and tweak JIT. In pointer compression mode, JRockit can already address 64GB. The garbage collector occupies on average 30% less than HotSpot.
If you are working with an Oracle stack on Linux or Windows, then Oracle recommends using JRockit. In all other cases - HotSpot.
Oracle wants to make Mission Control available for the new unified JVM. Redoing PermGen into native memory (C-heap). To make input-output without copying, for which you will need to implement a mechanism to prohibit the movement of GC objects in a certain processing phase. Make an API for managing the garbage collector and compiler. Add the ability to work with fragmented memory. Make it possible to run on bare metal. And of course, improved garbage collector in terms of predictable pauses.
Oracle does not intend to dwell on the merger, and in some perspective we can hope to see the NUMA extreme as a further development of care with NUMA. Even more predictable G1. The ability to run multiple applications in one JVM with the optional ability to effectively interact. Ergonomics on historical data and preliminary compilation. The idea is that when you start the application to use the data collected during previous launches and operation of the application. It is also planned to work on the possibility of efficient use of JVM in a cluster / cloud, when the resources allocated by the JVM may change. The possibility of supporting heterogeneous GPU processors is also being considered.
In conclusion, the speaker showed a standard slide on which it was said that everything said is the current plans of Oracle, which can change, and that they do not promise anything. He also recommended a link to the blog of an Oracle employee responsible for the JVM development strategy.
The reason for the merger of HotSpot and JRockit
This decision is due to cost reduction. Oracle noticed that customer requirements for both JVMs are in general the same, and users want to see the same things in both products. To achieve these goals, the developers of both JVMs independently come to implement the same ideas, for example, EscapeAnalysis and the predictable garbage collector (Garbage First from HotSpot and Deterministic GC from JRockit). So why ask duplicate work?
What JVM to take as a basis?
Each solution has its strengths and weaknesses. At the moment, HotSpot's strengths can be considered a wide area of use, a large customer base, high fault tolerance and performance. JRockit also stands out with its optimization for the stack of Oracle products on Linux and Windows, the availability of a soft real-time solution and a version to run on bare hardware without an operating system (of course, on a special hardware, and not arbitrary).
Surprisingly, there were long discussions of what kind of JVM to take as a base. As a result, it was decided in favor of HotSpot, but the arguments were not technical. The reasons were the existence of OpenJDK, made on the basis of HotSpot, the number of engineers working on HotSpot (engineers working on JRockit will implement the features of their offspring in the new common JDK), licenses issued by IBM, HP and other companies for modifying HotSpot. There is also sad news - not all merzh will fall into OpenJDK. The first results of the merge can already be seen in Java 7. For example, there it is already planned to translate PermGen to C-heap. To complete all the work on the merger is planned for two years.
')
Requirements for a modern virtual machine
What are the requirements for a modern virtual machine? The first is scalability. A virtual machine should work on a large range of machines, from cell phones to mainframes, allow working with large amounts of memory, work effectively on a large number of hardware streams (~ 10,000), and take into account the topology of memory. The second is speed. The virtual machine must be high-performance, predictable (JIT, GC), start quickly and have a small overhead (footprint).
Latest news and optimization HotSpot
NUMA allocation. Allows you to create an object in memory closer to the processor on which the work occurs. Since the probability that the thread created the object and will work with it more, then the profit on the face. Various tests showed an increase in performance from 25 to 300%.
Optimization of work with strings. It's no secret that various applications work a lot with strings, if not for pram, then various library methods still create them. For example, such optimizations were made such as string merging (-XX: + OptimizeStringConcat), string copying, string compression (-XX: + UseCompressedStrings, available only in 6u21p, then disabled), which allows storing characters in an array of bytes, if possible, and same string caching (xx: + usestringcache).
Compressed pointers. Enabled automatically if the JVM decides that it will give a profit. But you can enable it with the -XX option: + UseCompressedOops. This compression occurs due to shifts, which help to reduce the space lost during alignment. With this option, you can work with memory up to 32 GB. They say that it works even faster than the 32-bit JVM.
Garbage Firts. Starting with version 6u14, you can enable the -XX option: + UseG1GC. This collector is already working very stably, but not yet finished, as there are minor performance problems (spikes occur).
Step compilation. In order to have a quick startup, the JVM is launched with the client JIT compiler, after some time the compiler is changed to the server compiler.
And of course, EscapeAnalysis has already been pushed so many times and more efficient copying of arrays.
JRockit Benefits
On the front of JRockit, reliability and predictability can be distinguished. Using a consistent thread termination model. Powerful JIT compiler. API for testing plus a set of well covering tests (HotSpot is not enough for how much I know). Sampling compiler.
JRockit has a very powerful toolkit for support and debugging. You can highlight the presence of the so-called "flight recorder", which records everything that happened with the JVM and decoding which will help to understand when a non-standard situation occurs. To monitor the current state there is such a tool as Mission Control, which looks noticeably more powerful than the Visual VM for HotSpot. It is also possible to track native memory and tweak JIT. In pointer compression mode, JRockit can already address 64GB. The garbage collector occupies on average 30% less than HotSpot.
Which of the JVMs does Oracle recommend using now?
If you are working with an Oracle stack on Linux or Windows, then Oracle recommends using JRockit. In all other cases - HotSpot.
What functionality will be transferred?
Oracle wants to make Mission Control available for the new unified JVM. Redoing PermGen into native memory (C-heap). To make input-output without copying, for which you will need to implement a mechanism to prohibit the movement of GC objects in a certain processing phase. Make an API for managing the garbage collector and compiler. Add the ability to work with fragmented memory. Make it possible to run on bare metal. And of course, improved garbage collector in terms of predictable pauses.
Prospects for the development of a joint JVM
Oracle does not intend to dwell on the merger, and in some perspective we can hope to see the NUMA extreme as a further development of care with NUMA. Even more predictable G1. The ability to run multiple applications in one JVM with the optional ability to effectively interact. Ergonomics on historical data and preliminary compilation. The idea is that when you start the application to use the data collected during previous launches and operation of the application. It is also planned to work on the possibility of efficient use of JVM in a cluster / cloud, when the resources allocated by the JVM may change. The possibility of supporting heterogeneous GPU processors is also being considered.
In conclusion, the speaker showed a standard slide on which it was said that everything said is the current plans of Oracle, which can change, and that they do not promise anything. He also recommended a link to the blog of an Oracle employee responsible for the JVM development strategy.
Source: https://habr.com/ru/post/117386/
All Articles