Showing posts with label Garbage Collection. Show all posts
Showing posts with label Garbage Collection. Show all posts

Tuesday, November 19, 2013

Sickness & Taking Out The Garbage Scientifically

As the pills took hold of my internal (bodily) Garbage Collector and tuned it to more efficiently remove unneeded and unwanted objects, TheHackerCIO's thought naturally turned to his beloved JVM and it's own GC algorithms. For those more managerial, Garbage collection is part of the major advantage of Java over the old C and C++ environments. It allows the programmer to depend upon the environment to manage memory, rather than having to explicitly perform this in code.

There are two major advantages to using GCs. Memory management takes up a huge amount of development time, estimated by some at 40 to 60%! And secondly, if you mess up, it's easy to get a memory leak. Those are what cause your old windows box to hang on you, back in the day. The memory of your machine kept getting used up and never was released, so eventually there was no more memory left. So you were "hosed." That's a technical term. :-)

GC is an important issue in todays world, and I had been unsatisfied by the Java Performance book our Geeky Book Club read recently, most specifically by it's treatment of the GC algorithms. It seemed to be poorly organized from the standpoint of fundamental types of GC. Instead it plunged right in to the present state of GC available.

I was confirmed in this opinion by hearing a wonderful talk by Azul, who make a for-purchase JVM built around the idea of a "pauseless GC." In other words, in most GCs, when you collect the garbage, all work must stop. This is called "Stop the World," because all threads doing application work are stopped while the GC "pauses," collects the garbage, reclaims memory for new use, and then restarts the application. If the heap is big, a pause could be long. Maybe seconds. Maybe even 4-5 seconds? Now your talking availability problems!

Consequently, the GC needs to be understood. And tuned.

The talk by AzulSystems was far better organized. It cut through euphemism, defined and organized the presentation around fundamental GC types, then explored the currently available GCs and how they fit into those categories in terms of their performance characteristics. And the CTO mentioned that the bible for them was this book by Jones (image below), called The Garbage Collection Handbook:

So naturally, I ordered a copy.

The book is wonderful. I'm only on chapter two, but even if difficult/demanding, since it's well organized and doesn't leave dangling questions, it's a far better resource to read first, before attempting the Java Performance book, already reviewed here.

Plus, this is the absolute latest update on GC algorithms and technology! Further details will follow.

I Remain Thinking of Garbage,



Wednesday, October 2, 2013

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.