Scott Oaks - Java Performance

by Scott Oaks

Copyright 2020 Scott Oaks. All rights reserved.

Printed in the United States of America.

Published by OReilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .

• Acquisitions Editor: Suzanne McQuade
• Developmental Editor: Amelia Blevins
• Production Editor: Beth Kelly
• Copyeditor: Sharon Wilkey
• Proofreader: Kim Wimpsett
• Indexer: WordCo Inc.
• Interior Designer: David Futato
• Cover Designer: Karen Montgomery
• Illustrator: Rebecca Demarest

• April 2014: First Edition
• February 2020: Second Edition

See http://oreilly.com/catalog/errata.csp?isbn=9781492056119 for release details.

The OReilly logo is a registered trademark of OReilly Media, Inc. Java Performance, the cover image, and related trade dress are trademarks of OReilly Media, Inc.

The views expressed in this work are those of the author, and do not represent the publishers views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

978-1-492-05611-9

[LSI]

When OReilly first approached me about writing a book on Java performancetuning, I was unsure. Java performance, I thoughtarent we donewith that? Yes, I still work on improving the performance of Java (and other) applicationson a daily basis, but I like to think that I spend most of my time dealingwith algorithmic inefficiencies and external system bottlenecks ratherthan on anythingdirectly related to Java tuning.

A moments reflection convinced me that I was (as usual) kidding myself. Itis certainly true that end-to-end system performance takes up a lot of mytime, and that I sometimes come across code that uses an O(n2) algorithmwhen it could use one with O(logN) performance. Still, it turns out thatevery day Ithink about garbage collection (GC) performance, or the performance of the JVM compiler, or howto get the best performance from Java APIs.

That is not to minimize the enormous progress that has been made in theperformance of Java and JVMs over the past 20-plus years. When I was a Javaevangelist at Sun during the late 1990s, the only real benchmark availablewas CaffeineMark 2.0 from Pendragon software. For a variety of reasons,the design of that benchmark quickly limited its value;yet in its day, we were fond of tellingeveryone that Java 1.1.8 performance was eight times faster than Java 1.0performance based on that benchmark. And that was trueJava 1.1.8 had anactual just-in-time compiler, whereas Java 1.0 was pretty much completelyinterpreted.

Then standards committees began to develop more rigorous benchmarks, andJava performance began to be centered around them. The result was acontinuous improvement in all areas of the JVMgarbage collection,compilations, and within the APIs. That process continues today, ofcourse, but one of the interesting facts about performance work is that itgets successively harder. Achieving an eightfold increase in performance byintroducing a just-in-time compiler was a straightforward matter ofengineering, and even though the compiler continues to improve, were notgoing to see an improvement like that again. Parallelizing the garbagecollector was a huge performance improvement, but more recent changeshave been more incremental.

This is a typical process for applications (and the JVM itself is justanother application): in the beginning of a project, its easy enoughto find architectural changes (or code bugs) that, when addressed, yieldhuge performance improvements. In a mature application, finding suchperformance improvements is rare.

That precept was behind my original concern that, to a large extent,the engineering world might be done with Java performance. A few thingsconvinced me I was wrong. First is the number of questions Isee daily about how this or that aspect of the JVM performs under certaincircumstances. New engineers come to Java all the time, and JVM behaviorremains complex enough in certain areas that a guide to its operationis still beneficial. Second is that environmental changes in computingseem to have altered the performance concerns that engineers face today.

Over the past few years, performance concerns havebecome bifurcated. On the one hand, very large machines capable of runningJVMs with very large heaps are now commonplace. The JVM has moved to addressthose concerns with a new garbage collector (G1), whichas a newtechnologyrequires a little more hand-tuning than traditional collectors.At the same time, cloud computing has renewed the importance of small,single-CPUmachines: you can go to Oracle or Amazon or a host of other companies and cheaply rent a single CPU machine to run a small applicationserver. (Youre not actually getting a single-CPU machine: youregetting a virtual OS image on a very large machine, but the virtualOS is limited to using a single CPU. From the perspective of Java, thatturns out to be the same as a single-CPU machine.) In those environments,correctly managing small amounts of memory turns out to be quite important.

The Java platform also continues to evolve. Each new edition of Javaprovides new language features and new APIs that improve the productivityof developersif not always the performance of their applications. Bestpractice use of these language features can help differentiate betweenan application that sizzles and one that plods along. And the evolutionof the platform brings up interesting performance questions: there is noquestion that using JSON to exchange information betweentwo programs is much simpler than coming up with a highly optimizedproprietary protocol. Saving time for developers is a big winbut makingsure that productivity win comes with a performance win (or at least breaks even) is the real goal.