|
|
|
|
Back to newsletter 175 contents
Some gems in this weeks extracted tips, with my additional comments in [] square brackets:
1. "When one thread writes to a volatile variable, that write is not
the only thing visible to other threads; other threads see ALL the
writes visible to the thread that wrote to the volatile variable"
[That's a nice bit of arcane Java memory model detail, some people
think it's just the variable write that is visible.]
2. "Avoiding allocation in the core processing let's you avoid GC
pauses completely, but requires very specialised programming styles.
Going offheap avoids GC but is still allocation - you have to manage
it instead of the JVM. Initialising all objects before core processing
is a more common technique"
[The panel also pointed out that although there is a lot of interest in
these techniques, there are very few applications that really need them.]
3. [Combining a couple of tips here: the Java performance panel pointed out some nice pause targets: you can probably get the Oracle JVM down to about 5ms pauses if you are very careful with your code, but most code that uses third-party libraries will have a really hard time getting it down to 10ms.]
4. "@Contended is available in Java8 (you need to turn a flag on) and
it keeps fields apart so that they don't get generated into the same
cache line, thus avoiding false sharing"
[The flag is -XX:-RestrictContended, ie actually you need to turn OFF
the restriction that is in place by default; you can mark a class or
fields as @Contended; there's an additional flag -XX:+PrintFieldLayout
to see the results of the padding.]
5. "-XX:+UseCondCardMark can make multi-threaded code faster"
[This relates to how the garbage collector determines which objects
are live; there is an inefficiency in some GCs that mean when there
is a high concurrency level this card marking can be contended, setting
this flag improves the performance for those cases; some experts
suggest setting this flag by default.]
6. [Randy Shoup points out that using bell curve statistics is almost always wrong for performance issues; instead focus on percentiles, and especially worst cases.]
7. "To find classloader leaks, take a heap dump with
jmap -dump:format=b,file=dump.hprof "process-id"
, open that in a heap dump analyzer (eg Eclipse MAT) and look for
duplicate classes, especially related to your application. The
shortest path to the GC roots of inactive classloaders will
identify where the leak is occurring from"
[Always nice to have a simple description of how to solve a known problem.]
8. "The highest priority is that the system should be available"
[And good to remind ourselves of the top priorities, to keep us focused.]
Now on to all our usual sections: links to tools, articles, news, talks and as ever, all the extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 175 contents
