Back to newsletter 055 contents

You might think that two threads of the same priority both repeatedly contending for the same lock would overall get to lock it for the same number of times. But a fascinating point, backed by observed behavior, was raised by Billy Newport in this server side discussion.

Where the contention is bursty - which it often is in high-load systems - the operating system can favor one thread over the other because the thread releasing the lock is already running, and so has a lower context switching overhead to re-acquire the lock than the other waiting thread. The result can be that one thread gets a disproportionate amount of access through a critical section, starving other threads and unbalancing your application.

Solutions to this situation include yield()'ing more often; alternative patterns such as the Gatekeeper one that inspired the discussion referred to; explicitly queueing requests to acquire the resource (instead of using the implicit Java queues associated with each monitor that you get with synchronization); or at a higher level using communicating sequential processes (CSP), a framework that is currently being explained in three articles over at IBM developerworks.

A note from this newsletter's sponsor

In the newsletter we list our usual raft of articles, news and tools, and more. Kirk delves into reachability of objects, removing duplicates from lists, helping HotSpot compilation and much more in his roundup of performance discussions; and we have over 50 new performance tips extracted in concise form.

And a final mention - those of you in London on the 15th July might want to join me for lunch at the Sun central London offices for the latest JSIG seminar - see our first news item below.

News

Java performance tuning related news.

• The Need For Speed: The Ins and Outs of Profiling Java Applications: JSIG seminar on 15th July in London
• BEA's JVM JRockit has an interactive memory leak detection tool, the JRockit Memory Leak Detector, which allows usage while the system is running at almost full speed (technology preview in 1.4.2_05).
• New version of GCViewer, interactive GC log viewer
• Free Seminar (July 7th London): Clustering Performance Challenges and Solutions
• Java performance today
• Cameron Purdy webinar presentation on "Architecting for Scalable Performance using Clustered Caching,"
• New Java license lets developers easily make changes to the JDK for internal deployments. "The JIUL is a license created specifically for businesses and organizations who need to make small changes to a Java technology in order to fix critical bugs and/or address specific performance issues for their internal use."

A note from this newsletter's sponsor

Tools

• SwingWorker is designed for situations where you need to have a long running task run in a background thread and provide updates to the UI either when done, or while processing.
• ConcurrentTesting - Advanced Testing for Multi-Threaded Applications. A tool for testing, debugging, and coverage-measuring of concurrent programs.
• Terracotta - Java clustering & caching without API's
• Hermes JMS - provider-independent JMS monitoring and interactivity
• Lint4j static Java source and byte code analyzer that detects locking and threading issues, performance and scalability problems.
• Unified I/O allows high performance random access to any data or stream (even over HTTP), and gives a clear difference between read only and read/write access.

Recent Articles

• Tuning Your Stress Test Harness (Kirk Pepperdine/TheServerSide)
• Timing is Everything (Chet Haase/Sun)
• Interview with Chet Haase (Martin Perez/javahispano)
• Build Java Apps that Can Multitask (Raghu Donepudi/DevX)
• Maximize J2EE and database interoperability for performance (Robert Maness/Javaworld)

Jack Shirazi

Back to newsletter 055 contents