Updated OpenJDK Proposal: Late Barrier Expansion for G1
There is a good change coming to the G1 Garbage Collector, lowering the memory and processing overhead and speed. This is to speed up the execution of Java's C2 optimizing the JIT (Just in Time) Compiler. This should benefit cloud deployments, enterprise applications, and game servers – such as Minecraft, which is notorious for its garbage collection.
The new OpenJDK Proposal will try to simplify the implementation of G1’s barriers – which record information about application memory accesses by shifting their expansion from early in the C2 JIT's compilation pipeline to later. The proposal states are the feature change goal.
The changes are being proposed because of the increasing popularity of cloud-based Java software deployments. The most important thing to take away from this proposal is the stronger focus on reducing the overall Java Virtual Machine (JVM) overhead. Other important goals of this plan include reducing the execution time of the C2 while using the G1 Collector, creating barriers for the HotSpot developers that lack an understanding of the C2, and guaranteeing that C2 preserves invariants of the relative ordering of memory accesses, safepoints, and barriers.
Do you like what you are reading? We do recommend this next article – Understanding Heap Memory in Java Applications – to you to continue learning with us.
ExiledTech
t should also be remembered that the proposal's goal is not to retain the state of the G1 early barrier expansion as a legacy mode but to add that the switch to the late barrier expansion should be completely and fully transparent. This would make the legacy mode unnecessary. The proposal was originally created in December 2023 and was updated last week.
With the explanation of the proposal for the planned changes, it cites the increasing popularity of cloud deployments and the significant overhead incurred by JIT optimizing compilers such as C2. Some of the testing so far that has been done shows that expanding G1 barriers early increases C2 overhead by about 10% to 20%. Please remember that this is also per software application. Reducing this overhead is really good and is a major key to making the Java platform a better fit for the cloud.
Another thing that is worth noting is that another major contributor the Java Virtual Machine overhead is the garbage collector (GC). Decoupling the G1 barrier instrumentation from C2 internals would allow GC developers to further optimize and reduce the overhead of G1. This would be due to both algorithmic improvements and low-level micro-optimizations.
Last but not least, the proposal notes that the scope for C2 to optimize barrier code itself is limited and that code of similar quality could be generated if the barrier implementation details were hidden from C2 and expanded only at the end of the compilation pipeline. The Authors of the proposal therefore propose to expand G1 barriers as late as possible in C2’s compilation pipeline for overall better performance for Java software applications.
I am going to create a very simple program that creates a lot of temporary objects. The code we are going to use is right below.
public class MemoryLoadExample {
public static void main(String[] args) {
for (int i = 0; i < 1000000; i++) {
String temporary = new String("This is a temporary string");
}
}
}
In this example right above, Java creates a million temporary string objects. With the current – and usually the default Java settings of a software application – the G1 and C2 setup, each creation might be more costly than necessary due to early barrier expansion. The proposed changes could streamline the processing of such code, reducing the overhead during compilation, and can easily improve runtime performance for the application.
Oracle continues to make amazingly good changes and proposals to Java, but it also makes the lives of Java developers easier and codes more effectively for enterprise applications. Developers and System Architects should keep a close watch on these proposals as they come out. They are excellent potential for significant performance gains in their Java applications.
Do you like what you're reading from the CoderOasis Technology Blog? We recommend reading our Hacktivism: Social Justice by Data Leaks and Defacements as your next choice.
ExiledTech
The CoderOasis Community
Did you know we have a Community Forums and Discord Server? which we invite everyone to join us? Want to discuss this article with other members of our community? Want to join a laid back place to chill and discuss topics like programming, cybersecurity, web development, and Linux? Consider joining us today!
