Trash talkin’

Talking Garbage Collection with Gil Tene, Azul Systems

Chris Mayer
garbage-collection

We chat to Azul Systems CTO Gil Tene about a Java topic all developer want to understand further – garbage collection

After selling out a London Java Community meetup (so to speak),
it seemed rude not to catch up with one of the key men behind the
radical rethinking to JVM garbage collection, Azul Systems’s Gil
Tene. Here’s Part 1 of our chat, delving into different approaches,
the origins and upcoming trends. Make sure to check back on
Wednesday for part two of our exclusive interview.

JAX: Obviously garbage collection has been around for
decades – can you detail the origins of GC?

Gil Tene: The wider way of looking at garbage collection or
automatic memory management is something that has been around for
quite some time, probably a good four decades with a lot of good
academic work on it – interestingly a lot of that was done during
the 70s and 80s and more groundbreaking stuff recently.

What is garbage collection good for? It seems sort of obvious but a
lot of people seem to think of it as ways to let lazy programmers
that are not very skilled still program. But I think there are very
important industry trends that come out of it and now that Java and
other platforms are dominant in parts in the industry, we can see
the effect of what that does to actual productivity.

JAX: Does it differ depending on the working
environment?

GT: The first thing is that if you work in a mixed environment, or
compare environments where people code in Java or C# to those
programming in C and C++, what they do is build applications that
support, maintain and enhance over time. They don’t look at the
time to initial delivery so much as a year and a half or two years
into a project. My experience of embedded systems, servers and
software you shift is that when the stuff is built in C and C++,
you get it stable, you get it shipping and then you have these rare
things that crash and you spend about half of all your engineering
efforts trying to figure out what the rare crashes are.

When you look at core Java, they spend their time debugging other
things. It’s not that they don’t have bugs, but it’s very rare that
they look for crashing bugs, they usually end up looking for
functional bugs, enhancements and slowness and other things. The
other part that is not so obvious. Automatic memory management is a
core requirement almost for an effective framework ecosystem and
leveragable software. That is not an obvious thing to most
people.

JAX: So do you think Java developers, in general, care
enough about GC? Do they put it at the back of their
minds?

GT: I think they predominantly don’t care. And I think that’s the
right way – they shouldn’t care. When they run into tuning in
production, they end up caring for practical reasons but I actually
think the term GC-friendly programming or heap-friendly programming
is a symptom of a really bad execution on a garbage collection
side, not a good thing for programmers to do. Saying heap-friendly
programming is kind of like saying 16bit-friendly programming. It
should be considered that way.

If a collector can’t give you the invisible experience, then the
collector’s broken, the JVM’s broken and it’s a toy that isn’t
working right and you should be programming better.

JAX: Shall we move on to more specific garbage collectors
and what typical things they do?

GT: I think that if you look at garbage collection implementations,
the modern mature runtimes such as Java and .NET, Ruby and others –
the evolved garbage collectors which are pretty good. Usually
you’ll see precise garbage collectors, one that knows where all the
pointers whenever it collects, so it can move objects around for
example, it can compact memory. You can’t do that if you can’t fix
the pointers.

As far as techniques go, there’s no commercial JVMs that don’t do
that, it’s a given. Generational collection, observation that young
generation focus on recently allocated objects produces efficiency
– again it’s a universal practice and every JVM on a server.
There’s ways to run without that, but usually you don’t get very
good throughput or scalability.

JAX: What particular trends appear to coming through,
particularly in a Java context?

Over the past 15 years, certainly since Java started, we keep
improving garbage collection but the way people tend to improve it
is by taking the really bad thing that’s happening and trying to
make it happen a little less often. So, pushing it into the future
and further into the future rather than taking it on and figuring
how to solve it.

JAX: Does that mean the mindset needs to change
dramatically?

GT: I think so. In effect, our design for GC started nine years
ago. It was started from the simple statement of saying that that
trend is not sustainable – we have to go in the exact opposite
direction. Rather than figuring out how to take a problem and
ignore for a little longer. Instead of a few seconds, it’s going to
be a few minutes, maybe hours. That’s the Microsoft Windows 95
approach to stability. And we stopped making fun of Windows laptops
and rebooting because Java needs to rebooted more often than a
Windows laptop.

The opposite direction is find that thing, solve it and maybe by
solving it, all this other crud you had to do avoid it, doesn’t
even have to be done. That’s the choice we made nine years ago. So
far, I don’t see it as something the industry has followed but I do
think that it is unavoidable that everybody will have to choose
that other path. The path of delaying the problem even longer is
running out of steam. Or arguably already has run out of steam five
or six years ago.

Within that, there’s various modes. You’ve got non-compacting
collectors, the fall-back compaction, incremental compaction,
default and full compaction. Then there’s mostly concurrent, mostly
incremental, mostly non-stop the world. The word mostly means,
sorry I can’t deliver except for some of the time. All those are
common exercises in delaying. Every time you add to them you buy a
little more time.

JAX: To an outsider, the jargon with garbage collection can
be a bit perplexing at first. Can you attempt to classify the key
terms?

I have this talk (see below) which defines terms, types and
classifies metrics and puts it all together to classify modern
collectors. I like to distinguish concurrent collection from
parallel collection. Concurrent collection happens without stopping
the application, parallel collection can use more than one thread
at a time.

browser does not support iframe

JAX: Obviously Azul Systems has a spin on things – care
to explain how Zing differs?

The C4 collector has two main behaviors that are visible from a
classification perspective. First, it has got a single pass
concurrent marker. Guaranteed, regardless how fast you change or
mutate the heap, the marker will always complete and never have to
revisit what you’ve touched. Because of that it is independent of
application throughput.

It has a concurrent compactor that allows us to move objects
without stopping the application and more importantly allows us to
fix pointers without stopping. That’s one of the key difference
from the other commercial collectors. It has this for both the old
gen and the new gen – it’s actually the same collector. It has zero
stop the world fallback code. In practical terms, this results in a
compactor that is not sensitive to heap size, it’s not sensitive to
allocation rate or mutation rate. None of those things will affect
pause time or response time.

JAX: I’m guessing it thrives under high pressure
situations?

GT: It does very well but actually it was designed to work across
the whole spectrum.

JAX: What mistakes are common when tackling garbage
collection?

GT: From a developer perspective, obviously I’d like to see people
use those collectors and never look at them. But given that Zing in
its native Linux form is a new thing, relatively young less than a
year, the same techniques aren’t available on other vendors. I
think developers do what they have to do and use a lot of duct tape
and work with reality and make their applications work as well as
they could be expected to. So when I see people program in a
GC-conscious way, I don’t think they’re doing something wrong. I
think it’s sad that they have to do that. But good engineers have
to solve real world problems.

Part 2 of our interview with Gil will appear on Wednesday,
where we discuss his company’s role in the Java Community Process,
and Java 8. Photo by
brianfuller6385
.

Author
Comments
comments powered by Disqus