Interview

Kirk Pepperdine on the G1 for Java 9: “I’d like to see more time before making it the default”

Coman Hamilton
Rubbish bins image via Shutterstock

As news recently broke of the G1 Garbage Collector being named the default for Java 9, we got in touch with well-known Java mechanic and tuning specialist Kirk Pepperdine to hear his thoughts on the new standard.

JAXenter: Would G1 as a Standard Garbage Collector be an improvement for Java?

Kirk Pepperdine: This is a difficult question to answer. On the one side, we don’t really know how many people take the time to explicitly set their collector on the command line. Of course for those that do explicitly set the collector, this change will have no effect on them. I can imagine there is another group that is happy with the default and have decided not to explicitly set it.

One might say that this is irresponsible. However, if you want to be completely safe, you’d have to set all 688 flags to make sure their values didn’t change. So for these people and those that either don’t know or don’t care, it’s hard to say if the switch would cause any grief. Truth be told, we simply don’t know and I don’t think there will be an easy way to find out.

The argument for is that the collector is stable enough and it’s time to move to the future with this one size fits all collector. If there are further problems to be discovered, than the best way to discover them is to have the collector face a broader spectrum of use cases. The argument against is that there traditionally has been a conservative position whenever considering changes to Java. To subject users who have never had to tune GC with that possibility could be seen as being irresponsible. As I said, this is a difficult question to answer.

My personal view is that I think it’s a bit early to make this change. My reasons are; the collector has only moved to what I’d consider to be stable enough for production environments. I’d like to see more time before making it the default. Certainly by Java 10 one would hope that the G1 could be made to be the default. Secondly, I don’t think we really know how to tune it. Fortunately, my experience is that you don’t have to tune it very often. However when you do need to tune it, well, lets just say I don’t think we have the tools that we need to tune this collector just yet.

What do you make of the fact that it has been announced rather late in the development process?

I see this as some very keen people saying, yes, now we’ve cracked it and it’s ready for real action. It’s great to see this level of enthusiasm. We just can’t let it taint decisions given where JVMs live out there in the wild.

So the G1 is particularly suitable for low-latency applications – but if you’re not working on a low-latency area, is it going to give you a hard time?

Currently CMS is still better suited for low latency applications. There are still some unfortunate implementation details that continue to couple heap size to pause times. There are some other aspects of the G1 such as how it treats floating garbage that interfere with the collectors ability to consistently deliver low pause times. All of this is not a reason to change the default collector to the G1, as those working with low latency apps are very aware of the importance of tuning memory and GC. This is not the crowd I’m concerned with.

What’s wrong with the current garbage collection system?

For most applications there is nothing wrong with managed memory. In fact it provides applications with a level of safety that you simply could not see any other way. This level of safety allows us to do things that would otherwise not be possible. So, working in memory managed or garbage collected environments has been a huge enabler. That said, there are classes of applications that are sensitive to the stop-the-world pause that current implementations currently need to get the work done.

How long are these pauses? It’s tied to the implementations but in general it’s tied to the size of the heap, the number of live objects in heap and, to some extent, the rate of churn during concurrent phases. The G1 was suppose to break these relationships. It’s certainly weakened them but it hasn’t broken them. Another problem with the G1, at least in OpenJDK, is that it’s simply not concurrent as it could be. There are times when the GC threads need exclusive access to the Java heap data structures. To get this access it “gates” application threads at a safe-point. The current implementation indiscriminately safe-points *all* application threads whether or not they will interact with the data structure.

One would have wished that application threads that did not need to be safe-pointed would be allowed to run. However, it’s hard to criticize the current implementations as GC is a very difficult problem to solve. I think that those working on GC know that it could be better and they are working very hard to make it better but even so, we have to applaud what they have given us to date. Again, managed memory has been a huge enabler in this industry.

Author
Coman Hamilton
Coman was Editor of JAXenter.com at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous news, tech and culture websites and magazines, as well as several ad agencies.

Comments
comments powered by Disqus