Blued; NOT Screwed!

Blued; NOT Screwed! Which is to say "Zinged"!

TheHackerCIO is fluent in Spanish. So Azul Systems is "Blue" to him. Last night at the LAJUG we were amazingly lucky enough to get a tremendous presentation on Java Garbage Collection from the CTO and Cofounder of Azul Systems,  Gil Tene.

Azul, for those who don't know, make a JVM which, while it costs money, resolves a lot of the performance problems commonly encountered in Java environments.


TheHackerCIO is never tempted to Lionize anyone, or write puff-pieces about any product. What set this presentation apart were the following:

• factual information about all available GCs was the main thrust of the talk.
• Zing (Azul's product) was only mentioned briefly at the end.
• Basic terms were defined, some in cleverly clear ways that made for greater retention
• Basic principles were developed.
• Principles of GC operation were then examined in the context of those basic terms and principles, so that everything was brought into a coherent whole.
• The focus was on understanding the Mechanism, not on explicating the JVM flags. As Gil put it "Once you understand how it works, you can use your brain" to figure out the flags. TheHackerCIO likes that. Always use your brain.
• A lot of misinformation and fallacies were debunked. Turns out, surprise, surprise, the Conventional Whiz-Dumb is wrong much of the time. 

The presentation was so superior to the Performance book, that in my mind it formed a perfect contrasting concrete. If only the Performance book we are studying had been written in this manner, we would have all been happy campers. 

I took pages of notes, and I suspect that I'm going to have to break them out over several days. But, you have to start somewhere. And what better place than his attention step?

He began by claiming that most of what people "know" about GC is wrong. Then he told a story

Early in Azul's history they encountered an application taking 18 second pauses. This was somewhat embarrassing for a pause-less JVM, so they investigated. What they found was that every class had a finalizer that set all instance variable references to null. 

Notice that this is the right discipline for a C++ environment. But it's dead wrong for Java. Dead objects cost nothing to collect! Except, when you put finalizers on them! This is a perfect example of how people fail to rethink new technology in the context of it's own spirit and intent and continue to use it in antiquated, outdated manner. But that is a major topic for yet another day's blog, and was not a topic of Gill's talk. 

So, despite the Conventional Whiz-Dumb:

• GC is extremely efficient. Much more so than malloc().
• Dead objects cost nothing to collect (Except when you put finalizers on them!)
• Those pauses you eliminated from your 20 minute test are not really gone. They just got pushed out to 30 minutes. Your times may vary, but the pause just got pushed out to a later time!
• There will be a 1s per live GB pause. This is not really tunable. The only way around it is Zing.
• No, GC doesn't mean that you can't have memory leaks.

Even I fell for some of these in times past. But this is getting long. 

I would say in conclusion that rarely have I been so impressed by a company's values. The talk we scored came from Azul honoring the commitment of a junior sales engineer to speak to us in October, but who had left the company. In the absence of anyone local to fill in, the Cofounder/CTO hopped on a plane to give us the promised presentation. TheHackerCIO deeply respects keeping commitments and  can't think of a more paradigmatic example. More on GC will follow.