Why open up a black JVM box - Interview with Charles Nutter, Red Hat JVM developer
Autumn is a great time to meet old friends, travel to conferences, walk in parks. Many have already returned from the holidays with new impressions, ideas, ready to share them, communicate with others. Our interview today is not about traveling, although undoubtedly, diving into the world of Java can also be called such. Talk about JVM. Our interviewee is Charles Nutter , JVM developer at Red Hat, lead engineer for the JRuby project.So, stock up on coffee and start.
')
“Our theme today is JVM and its“ dark ”content. Charles, tell me, when did the JVM stop being a mystery for you?
Yes, the feeling of working with a black box, there is a majority of users of the Java virtual machine, with whom I am familiar.
I think that the learning process started when I released open source OpenJDK. Around this time, I began to understand how the JVM works. At that time, behind the back was already ten years of experience of the developer. The interest was to understand what was really going on behind the scenes, in key places of the JVM. Not to say that at that moment I was picking exactly in the guts of the Java virtual machine.
That all changed while working on JRuby, a Ruby implementation running on the JVM.
In order to make the language useful and powerful, we began to closely study the JVM, the very secret places of the virtual machine. An understanding of how JVM works is required to work out optimization algorithms.
Together with the engineers working on the JVM, we developed functions, such as invokedynamic, for example, that help functional languages, in our case, JRuby.
So after ten years of working on JRuby, I gained the knowledge and experience of how the JVM works, and made a few of these dark spots a little less dark.
- What do you think about the outdated, but stubbornly entrenched in people's minds idea that Java is slow? How does the filling match the capabilities of the hardware today?
- The truth is that this issue was raised frequently by us as participants in the JRuby project. People who are not familiar with Java or with the JVM, heard about the idea of ​​implementing Ruby on it: Ruby is a language that is not considered fast, in Java, which, unfortunately, has an incorrect, outdated reputation for being slow. In such a performance language did not make sense to many people.
We had to solve this issue. The truth is that Java was slow fifteen years ago. The tremendous work on JIT compilers and the garbage collector has continued and continues to this day, every day. There are a lot of people left who were in the industry and remember the “bad times” of slow Java. Because of this, the myth does not disappear for so long.
Java is very powerful these days, but speed and many of the great features depend on JIT compilers and the garbage collector, which often leads to launch losses.
However, even today Java has something to improve, to optimize, for example - the time of the warm-up curve should be reduced for maximum peak performance. Fortunately, painstaking work continues on these things.
“One of the reasons that developers devote little time to studying the internal structure and operation of the JVM is that programs run perfectly in different environments and are not required to be rewritten and optimized for each platform. Do you agree with this thesis?
“The big plus of the JVM is that when you get the so-called black box, in most cases the developer does not need to look under the cover to understand how the JVM works and how it works. However, as in any operating systems, programming languages, libraries, frameworks that you use, knowledge of how they work, makes you better, more experienced.
In my case, we were forced to understand why the JVM is not always as fast as we want it to be. It was necessary to figure out what actions need to be done to teach the JVM to execute Ruby code faster.
It is necessary to look inside the JVM and understand how it works, from and to.
Many developers never get to this point of exploration. You know how the garbage collector, JIT compilers work, sometimes that's enough. It is normal when you do not know what is going on inside when you are developing applications. But there are cases when you may need maximum performance or other critical things for a large business, for some websites, at this very moment you will need the details that you will receive only during the “dive”.
“Or maybe it’s right that the developers don’t look into the JVM settings until they see the problem?” You can usefully spend this time writing new programs, right?
- Yes, I agree, this is exactly the real strength of the Java virtual machine. And that was one of the main reasons why Java has evolved so rapidly over the last twenty years. People can quickly develop applications, surprisingly quickly.
Obviously, I would never recommend everyone to delve into the work of the JIT compiler or read the code of the garbage collector. There are many features that you need to know and understand them, but this may not always be useful for everyday development.
I plan to tell a lot of interesting things on Joker 2016 , for example, how to look behind the scenes of JVM ... how to enable JVM JIT logging and see how the code is compiled, see what decisions the machine makes during optimization. You can go even further and start watching the code in assembly language if you have an algorithm or program that you want to optimize. You will not need to dive very deep into the depths of the JVM in order to come to a better understanding of how it works and how to make the JVM work for your application one hundred percent.
- During our dialogue, I had another question, at first glance, not related to the JVM. Do you think the modules and modular system planned for Java 9 will help with optimization issues?
“I followed the JVM modularization process.” There were conversations about breaking up into small parts for easy distribution while I was working at Sun Microsystem. I think that this is an amazing and at the same time complex work that is happening now, given the huge amount of code, including the internal structure of the JVM. Embedding the entire runtime in a whole platform on the JVM is a huge challenge.
There are a large number of dependencies within the main JDK classes with classes that we don’t see from the scene. What I really admire in modularity is the fact that we have an exact way to limit certain blocks in an application and all its dependencies. As in Maven at the time of assembly, it is now possible to transfer applications with all the other handy tools that will be released soon in JDK 9.
Another interesting feature in JDK 9 is the optimization of individual elements, the ability to analyze individual parts of the code and perform pre-optimization. This will help when loading, will increase the intensity of the warm-up, perhaps the implementation of early compilation.
Most of these things would be difficult to implement without modularity, we will get much more flexibility after its implementation.
- As we know, there are static and dynamic compilers. Why is it easier with Just-In-Time (JIT)? Please tell us how JIT mechanisms help to create faster sequences of instructions and replace instructions with more efficient sets.
- Static compilers should always make a forced compromise when making decisions about optimizing code, since it is more difficult for them to understand, to figure out how the program will behave during execution. This is the advantage of JIT compilers: they collect information about the objects used, the branches, and the methods called where the most code is executed. JIT compilers can use tricks such as embedding to combine methods and deoptimization, which allow aggressive code optimization with a safe rollback (for example, an interpreter or a less optimized version of code) in case these optimizations need to be changed.
- Another important part in the work of the JVM is the garbage collector. A few months ago, I read a note about Shenandoah garbage collection technology. “Shenandoah is a parallel and concurrent compacting garbage collector. It is a work that has been carried out.
Can you tell us about the work in this direction?
“I only have information about the Shenandoah project as part of what I read myself, but I welcome my friends at Red Hat to go beyond the limitations of OpenJDK.
Choosing a garbage collector is one of the most difficult problems for JVM users. Shenandoah falls into the group of garbage collectors focused on short pauses for large heaps, this is especially true now, in the era of big data. It attempts to improve the aspects of the CMS and G1 garbage collectors by providing a simultaneous heap compaction (plugging “holes” immediately after assembling objects) and using alternative strategies to correct objects while the application continues to work. It is undoubtedly worth exploring Shenandoah if you have a big heap and you need to keep the pauses to a minimum.
- Is there a possibility of "fine" settings of the garbage collector? How justified is the use of various garbage collectors (GC), and in what cases should this feature be used? What can you say about CMS GC and G1 GC? What kind of "tuning" can I use for tuning?
It was interesting to watch as the Concurrent Mark-Sweep garbage collector slowly began to give way to the G1. The first was a workhorse for many large JVM projects, despite the need to set up a bundle of non-obvious flags or to accept more frequent events of “concurrent mode failure”, leading to pauses in the system. G1 has been steadily developing over the past few years, and now it seems to be a more popular option for big heap and short pauses. That's a small recommendation, as I understand it, G1 is more tolerant of default settings. Setting up the garbage collector is unlikely to ever go away, but it seems to me that the trend is to perform specific tasks by the garbage collector without undue user intervention.
- We paid attention to such central topics as working with memory, compilers and garbage collectors. Maybe we missed something, and Java has not become clearer to us? What else is sure to tell, showing Java from the inside?
It is interesting to know how the JVM itself works, with its code, JIT compilers, memory model and garbage collectors, but many of the most interesting parts of Java live in the middle layers. Every Java developer must have a good knowledge of the bytecode JVM, from its initial structure to the moment it is executed by the virtual machine.
I think most Java developers will want to know how invokedynamic (added in Java 7) enhances the capabilities of new languages ​​on the JVM and new Java features. It is important to have a general understanding of the platform, even if you will never go deep into any layer.
- Finally, I would like to know a little about the innovations awaiting us in version 9, such as JVMCI and graal.
OpenJDK 9 will bring with it a new API called JVMCI. Using this API, the JIT compiler used by the JVM to optimize code can be changed using the command line. This option will be familiar to people who have ever moved to another GC, for those of us who remember the struggle with the “server” and “client” flags a few years ago. This will allow you to explore JIT compilers, such as the new Graal (written in Java JIT compiler, ready to compete with its own HotSpot JIT), without reconfiguring the JVM. Graal, in turn, is used to find new ways to implement high-performance languages ​​on the JVM, including a new Ruby implementation developed alongside the JRuby project. Now is a very exciting time to be on the Java platform!
- Thank you so much for the conversation.
On October 14 and 15 (Joker 2016 in a week!) Charles will make two hardcore presentations: keyout From Java to Assembly: Down the Rabbit Hole and a talk Let's Talk About Invokedynamic .
In addition, if you like the “guts” of the JVM just like us, then in addition to the reports of Charles Nutter, we recommend you to look at the following reports of Joker 2016:
Source: https://habr.com/ru/post/311660/
All Articles