Book Review: Java Performance 160
jkauzlar writes "The standard Oracle JVM has about sixty 'developer' (-XX) options which are directly related to performance monitoring or tuning. With names such as 'UseMPSS' or 'AllocatePrefetchStyle', it's clear that Joe Schmo Code Monkey was not meant to be touching them, at least until he/she learned how the forbidding inner recesses of the JVM work, particularly the garbage collectors and 'just-in-time' compiler. This dense, 600-page book will not only explain these developer options and the underlying JVM technology, but discusses performance, profiling, benchmarking and related tools in surprising breadth and detail. Not all developers will gain from this knowledge and a few will surrender to the book's side-effect of being an insomnia treatment, but for those responsible for maintaining production software, this will be essential reading and a useful long-term reference." Keep reading for the rest of jkauzlar's review.
In my experience, performance tuning is not something that is given much consideration until a production program blows up and everyone is running around in circles with sirens blaring and red lights flashing. You shouldn't need a crisis however before worrying about slow responsiveness or long pauses while the JVM collects garbage at inconvenient times. If there's an opportunity to make something better, if only by five percent, you should take it, and the first step is to be aware of what those opportunities might be.
| Java Performance | |
| author | Charlie Hunt and Binu John |
| pages | 693 |
| publisher | Addison Wesley |
| rating | 9/10 |
| reviewer | Joe |
| ISBN | 0-13-290525-6 |
| summary | Java performance monitoring and tuning |
First off, here's a summary of the different themes covered:
The JVM technology: Chapter 3 in particular is dedicated to explaining, in gory detail, the internal design of the JVM, including the Just-In-Time Compiler and garbage collectors. Being requisite knowledge for anyone hoping to make any use of the rest of the book, especially the JVM tuning options, a reader would hope for this to be explained well, and it is.
JVM Tuning: Now that you know something about compilation and garbage collection, it's time to learn what control you actually have over these internals. As mentioned earlier, there are sixty developer options, as well as several standard options, at your disposal. The authors describe these throughout sections of the book, but summarize each in the first appendix.
Tools: The authors discuss tools useful for monitoring the JVM process at the OS level, tools for monitoring the internals of the JVM, profiling, and heap-dump analysis. When discussing OS tools, they're good about being vendor-neutral and cover Linux as well as Solaris and Windows. When discussing Java-specific tools, they tend to have bias toward Oracle products, opting, for example, to describe NetBean's profiler without mentioning Eclipse's. This is a minor complaint.
Benchmarking: But what good would knowledge of tuning and tools be without being able to set appropriate performance expectations. A good chunk of the text is devoted to lessons on the art of writing benchmarks for the JVM and for an assortment of application types.
Written by two engineers for Oracle's Java performance team (one former and one current), this book is as close to being the de facto document on the topic as you can get and there's not likely to be any detail related to JVM performance that these two men don't already know about.
Unlike most computer books, there's a lot of actual discussion in Java Performance, as opposed to just documentation of features. In other words, there are pages upon pages of imposing text, indicating that you actually need to sit down and read it instead of casually flipping to the parts you need at the moment. The subject matter is dry, and the authors thankfully don't try to disguise this with bad humor or speak down to the reader. In fact, it can be a difficult read at times, but intermediate to advanced developers will pick up on it quickly.
What are the book's shortcomings?
Lack of real-world case studies: Contrived examples are provided here and there, but I'm really, seriously curious to know what the authors, with probably two decades between them consulting on Java performance issues, have accomplished with the outlined techniques. Benchmarking and performance testing can be expensive processes and the main question I'm left with is whether it's actually worth it. The alternatives to performance tuning, which I'm more comfortable with, are rewriting the code or making environmental changes (usually hardware).
3rd Party tool recommendations: The authors have evidently made the decision not to try to wade through the copious choices we have for performance monitoring, profiling, etc, with few exceptions. That's understandable, because 1) they need to keep the number of pages within reasonable limits, and 2) there's a good chance they'll leave out a worthwhile product and have to apologize, or that better products will come along. From my point of view, however, these are still choices I have to make as a developer and it'd be nice to have the information with the text as I'm reading.
As you can see, the problems I have with the book are what is missing from it and not with what's already in there. It's really a fantastic resource and I can't say much more than that the material is extremely important and that if you're looking to improve your understanding of the material, this is the book to get.
You can purchase Java Performance from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Dead trees == outdated as soon as printed (Score:2, Insightful)
Why in the fuck was I modded troll?
Good question, but this follow up statement may be holding a clue:
I guess the repugnant little asshats pushing this book must have some points. Fucking worthless pathetic immoral assfuckers.
Yeah, that blurb didn't help ya.
Re:Futile (Score:5, Insightful)
There is a _big_ difference between clumsily optimized (or unoptimized) Java and carefully-optimized Java--more, in my experience, than the difference between clumsily optimized Java and clumsily optimized C or C++. So if you are already using Java for some reason (robustness to faults, ease of parallelism of certain kinds (w.r.t. C), library that does exactly what you need, etc.), you should figure out how to optimize it before bailing out and using a different language.
Only if you absolutely must get as much out of your hardware as physically possible should you start using C/C++, and at that point, don't expect to be using ANSI C; you should be issuing SSE4 instructions and such (basically writing targeted assembly, even if you are doing so in a way that looks like C functions) that have been cleverly crafted to do exactly what you need.
(And don't forget that while you are taking extra time to write all this low-level high-performance code, your computers _could_ have been running using the slower code, making progress towards a solution, or serving customers albeit with delays, etc..)
Too many options (Score:5, Insightful)
Re:Futile (Score:5, Insightful)
Fair points but I'd say there's a few places that Java just doesn't cut it - strict scheduling and / or real time needs. O, and GUI stuff, too.
So basically, no GUI, no audio, no video. Which only more or less leaves what it currently is king of the hill for - server side business processing.
I've tried real time and Java, and the jitter that garbage collection introduces (yes, even with parallel garbage collection and all that stuff) makes it hugely unpredictable.
Strangely enough, the company formerly known as SUN knew this, and tried to create a "real time" [sun.com] flavour of Java with such extensions - but it takes so much effort to port your code (and the JVM is slightly less than brilliant) that you're far better off going to C/C++.
Re:Futile (Score:4, Insightful)
Re:Futile (Score:5, Insightful)
Oh, please, neither Java nor C++ is superior to the other. They both have strengths at certain kinds of programming but altogether support extremely similar semantics in most areas. There are very difficult-to-use portions of both Java and C++. You should get yourself some more experience.
Re:Futile (Score:4, Insightful)
Unfortunately, when you really get down to it you will have similar problems in C or C++. You cannot allocate memory from the system heap (malloc or operator new) in the critical path of real-time code. That means everything is preallocated. That means you could have been using Java anyways, with GC disabled. There may be other reasons to use C or C++ for these systems, but the nondeterminism of dynamic memory allocation really applies across the board. It just hits Java users earlier.
Re:Futile (Score:4, Insightful)
Woah, browsers! Nice one, in that way you let out QT, which only runs on Window, Mac and Linux. And blows SWT out of the water in every way.
Re:Futile (Score:4, Insightful)
Maybe you could use JNI for that, in certain very specialized cases, but if you write parts of your application in C/JNI you run the risk of just combining Java's weaknesses (memory, performance) with C's weaknesses (error prone). A nullpointer in a native code part of your application will unceremoniously crash your JVM and everything running in it.
JNI is often used for things that can only be done in native code. An example I can think of are atomic compare and swap operations in the java.util.concurrent package. These are implemented via a JNI method essentially calling just one machine instruction (on Intel, it may be a hand full on some architectures). Yes, this is for performance reasons - an atomic compare&swap is faster that using locks, not because native code runs faster but because it's the only efficient way to implement it.