Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up! 

News January 2014

jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

Site24x7
Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up!


jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 158 contents

With the highest performance highly concurrent systems, the highest efficiency is increasingly targeted at non-locking algorithms. That doesn't always mean compare-and-swap, but often it does. To remind you, with a compare-and-swap operation you pass the existing value and the new value you want to store; if the compare-and-swap finds that the actual value currently stored is the "existing" one you passed, then it will store the new value you passed, otherwise it won't (because something else has changed the value since you got your "existing" one). The return code/object tells you whether the operation succeeded or failed (the "swap" tells you it returns the value that was at the location before it was overwritten if successful). Compare-and-swap operations are usually much more efficient than locking to update a value for two reasons: the cost of obtaining a lock is relatively high; and most values are read more often than they are updated. Locking is considered a pessimistic approach - you're assuming the worst case, that something else will try and change your value while you do, and so you lock them out so that you can guarantee you don't waste your operation. Compare-and-swap is an optimistic approach - you assume that mostly nothing else is going to change the value when you are, so it's best to just give it a go, and deal with (hopefully) the odd failure with a retry.

A note from this newsletter's sponsor

Get total visibility in just 15 minutes with AppDynamics PRO,
A performance monitoring tool for Java/.NET apps.
It installs in minutes. Start your FREE TRIAL today.

This should tell you that there are scenarios where locking can outperform a compare-and-swap approach, specifically where there are a high number of concurrent writers on a value. In this situation, compare-and-swap fails a lot and many threads can end up spinning as they keep retrying compare-and-swap operations; in contrast the lock is guaranteed to succeed it's update once the lock is obtained, no retries are needed, so fewer overall register executions will result in that high contention scenario.

Now step back to last November's newsletter. I included reference to, and extracted tips from, an article entitled "Lightweight Contention Management for Efficient Compare-and-Swap Operations". What this provides is a way to shift the point when locking becomes better than compare-and-swap quite a way - quite likely to where you are almost always better off using compare-and-swap. The technique is quite simple - just backoff (i.e. pause) before retrying the compare-and-swap operation when it fails. The article goes into multiple different strategies for determining how long to wait, but finds that the simplest - a constant small wait - is highly effective, in some cases providing an order of magnitude improvement in throughput of update operations! What this backoff does is give the other contending threads just enough time to slip in and update so that when it comes back to your thread's turn, it's got a gap where it can also slip in and do it's update. This technique should become part of your standard armoury if you are working on highly concurrent systems.

Now on to yet more links to Java performance tools, news, articles and, as ever, all the extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

ManageEngine's Site24x7 : Deep dive Application Performance Monitoring
Fix performance issues with Java, .NET and Ruby platforms.
*** Monitor one app instance at $9 per year***

News

Java performance tuning related news.

Tools

Java performance tuning related tools.

A note from this newsletter's sponsor

New Relic - Try New Relic today and get your free Data Nerd shirt!
Free SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

Articles

Jack Shirazi


Back to newsletter 158 contents


Last Updated: 2017-05-31
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news158.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us