Skip to main content

Java Performance Talk

Paul Tyma and I gave a talk at SD West today on Java Performance Myths.

The big takeaway was this: Most of the things you think you know about Java performance are really hard to quantify. Write the best code you can. Profile it to find the bottlenecks. Remove the bottlenecks. Rinse and repeat.

A couple of other takeaway points here:
  • Don't forget to upgrade every so often. JDK6, for example, runs code compiled for JDK4 just fine, and you get a big performance boost. For free.

  • Memory allocation is pretty cheap. Know that there are three garbage collectors, and know which one is best, when. Read the Java memory management white paper.

  • Hotspot can do lots of things to optimize your locks, but it often doesn't. Having said that, the bottlenecks in concurrent code usually have to do with contention, not synchronization overhead. Use low contention data structures like ConcurrentHashMap to avoid contention, but don't try to get clever with locking.

  • Contrary to popular belief, thread-per-request synchronous servers are often faster than selector-based asynchronous servers.

The Java Performance Myths slides are here.

Comments

Anonymous said…
Great talk! One of the most informative on SD West, BTW.

Thank you for posting the slides.

L Swanson
March 10, 2008 at 9:13 AM
Jeremy Manson said…
Thanks! We were happy to contribute! Well, that and they paid us.
March 10, 2008 at 9:25 AM
Anonymous said…
This talk is really helpful for us, as we are dealing with memory management and performance problems in our application. Thanks for posting the slides also.
--Dilli Babu N
March 18, 2008 at 10:14 PM
Mr President said…
I am unable to access the Java Perf Myths PPT.
November 17, 2008 at 10:26 PM
Jeremy Manson said…
Yup. I'm having hosting problems. Sorry about that.
November 17, 2008 at 11:13 PM
Shahbaz said…
@Even i too am not,could you please share it somewhere else or send to to my id.
November 21, 2008 at 11:32 PM
Anonymous said…
This comment has been removed by a blog administrator.
January 3, 2009 at 5:08 PM
Anonymous said…
This comment has been removed by a blog administrator.
January 3, 2009 at 5:10 PM
Unknown said…
This comment has been removed by the author.
February 19, 2009 at 5:56 AM
Anonymous said…
HI!
Sorry but How Can I download the slides?
It say I don't have the permission!! :-(
February 19, 2009 at 5:59 AM
Post a Comment

Popular posts from this blog

Double Checked Locking

I still get a lot of questions about whether double-checked locking works in Java, and I should probably post something to clear it up. And I'll plug Josh Bloch's new book, too. Double Checked Locking is this idiom: // Broken -- Do Not Use! class Foo {   private Helper helper = null;   public Helper getHelper() {     if (helper == null) {       synchronized(this) {         if (helper == null) {           helper = new Helper();         }       }     }   return helper; } The point of this code is to avoid synchronization when the object has already been constructed. This code doesn't work in Java. The basic principle is that compiler transformations (this includes the JIT, which is the optimizer that the JVM uses...
107 comments
Read more

What Volatile Means in Java

Today, I'm going to talk about what volatile means in Java. I've sort-of covered this in other posts, such as my posting on the ++ operator , my post on double-checked locking and the like, but I've never really addressed it directly. First, you have to understand a little something about the Java memory model. I've struggled a bit over the years to explain it briefly and well. As of today, the best way I can think of to describe it is if you imagine it this way: Each thread in Java takes place in a separate memory space (this is clearly untrue, so bear with me on this one). You need to use special mechanisms to guarantee that communication happens between these threads, as you would on a message passing system. Memory writes that happen in one thread can "leak through" and be seen by another thread, but this is by no means guaranteed. Without explicit communication, you can't guarantee which writes get seen by other threads, or even the order in whic...
176 comments
Read more

Atomicity, Visibility and Ordering

(Note: I've cribbed this from my doctoral dissertation. I tried to edit it heavily to ease up on the mangled academic syntax required by thesis committees, but I may have missed some / badly edited in places. Let me know if there is something confusingly written or just plain confusing, and I'll try to untangle it.) There are these three concepts, you see. And they are fundamental to correct concurrent programming. When a concurrent program is not correctly written, the errors tend to fall into one of the three categories: atomicity , visibility , or ordering . Atomicity deals with which actions and sets of actions have indivisible effects. This is the aspect of concurrency most familiar to programmers: it is usually thought of in terms of mutual exclusion. Visibility determines when the effects of one thread can be seen by another. Ordering determines when actions in one thread can be seen to occur out of order with respect to another. Let's talk about t...
52 comments
Read more