Back to newsletter 079 contents

http://www.fasterj.com/articles/bookwriting.shtml
Writing A Technical Book: Is It Worthwhile (Page last updated June 2007, Added 2007-06-28, Author Jack Shirazi, Publisher Fasterj.com). Tips:

• [Article by Jack Shirazi, the author of the successful book "Java Performance Tuning", considerations on writing a technical book].

http://www.ibm.com/developerworks/java/library/j-jtp06197.html
Managing volatility (Page last updated June 2007, Added 2007-06-28, Author Brian Goetz, Publisher developerWorks). Tips:

• Volatile variables share the visibility features of synchronized, but none of the atomicity features.
• Threads automatically see the most up-to-date value for volatile variables.
• volatile variables (unlike locks) cannot cause a thread to block, so they are less likely to cause scalability problems.
• You can use volatile variables instead of locks if: Writes to the variable do not depend on its current value AND the variable does not participate in invariants with other variables (i.e. basically the volatule variable value is independent of any other program state).
• Volatile variables cannot be used as thread safe counters (x++ is not an atomic operation) except if the update is only ever done by one particular thread.
• In some situations, volatile variables may be a better-performing synchronization mechanism than locking.
• On most current processor architectures, volatile reads are nearly as cheap as nonvolatile reads.
• Volatile writes are considerably more expensive than nonvolatile writes , but still generally cheaper than lock acquisition.
• The most common use of volatile variables is a simple boolean status flag: an important one-time life-cycle event has happened, such as initialization has completed or shutdown has been requested. This is a valid usage.
• A volatile reference to an object can guarantee the visibility of the object in its as-published form (the fomr when it was assigned to the reference).
• A volatile variable can be used to hold the latest of an independent observation - code consuming the value should be aware that it might change at any time.
• If reads are much more frequent than writes, a faster thread-safe counter can be implemented with volatile int value; public int getValue() { return value; } public synchronized int increment() {return value++;}

http://java.sun.com/mailers/techtips/enterprise/2007/TechTips_May07.html#2
How to Get the Best Performance Out of a Java Persistence Implementation (Page last updated May 2007, Added 2007-06-28, Author Rahul Biswas, Publisher Sun). Tips:

• Set the number of connections in the connection pool to the number of request processing threads.
• Increase the cache size in Toplink Essentials for better throughput.

http://weblogs.java.net/blog/sdo/archive/2007/06/dynamically_siz.html
Dynamically sizing threadpools (Page last updated June 2007, Added 2007-06-28, Author Scott Oaks, Publisher java.net). Tips:

• Dynamically-resizing threadpools can harm the performance of your system.
• The most important task of a threadpool is to throttle the number of simultaneous tasks running on your system, not to allow you to conveniently run multiple things at once.
• If you add more running threads to a saturated system, your throughput will go down: the threads will compete with each other for CPU and other system resources, and the operating system will spend more time than necessary managing the competing threads.
• You usually want (slightly?) more threads than CPUs to get optimal use of your system as tasks are never 100% CPU-bound.
• If you have more tasks to perform AND you have idle CPU time, then add more threads to the pool. Conversely with no idle CPU time, it is counter-productive to add threads to the pool.
• If a dynamically resizable threadpool chooses to add threads because there are tasks waiting (even though there is no available CPU time), it will hurt your performance rather than help it.

http://weblogs.java.net/blog/cayhorstmann/archive/2007/06/the_single_thre.html
The Single Thread Rule in Swing (Page last updated June 2007, Added 2007-06-28, Author Cay Horstmann, Publisher java.net). Tips:

• The original single thread rule for swing (Once a Swing component has been realized, all code that might affect or depend on the state of that component should be executed in the event-dispatching thread, i.e after pack or setVisible(true) only operate on the swing thread) has been superceded by: All Swing components and related classes, unless otherwise documented, must be accessed on the event dispatching thread.
• The preferred way to transfer control and begin working with Swing is to use invokeLater.
• The canonical way to apply the new single thread rule for swing is to put all activity including Swing component initialization into separate Runnable objects and call EventQueue.invokeLater(Runnable).
• The EventDispatchThread is created when the first event is posted to the EventQueue. That used to happen when the first frame was made visible, but now for some toolkits events are fired sooner, so the only safe course an application can take is to assume that the EventQueue is always active. (That's why the Single Thread rule for swing changed).

http://blogs.msdn.com/drnick/archive/2007/01/30/queue-scalability.aspx
Queue Scalability (Page last updated January 2007, Added 2007-06-28, Author Nicholas Allen, Publisher Indigo Blog). Tips:

• No matter how powerful the machine gets, it rarely makes sense to replicate an always-on service on a single machine.
• single machine scalability is achieved by adding more threads to a single process
• The optimum tuning point is where resources are never idle, but they're also not overcommitted and facing contention.
• An asymmetric farm, with machines of varying capabilities, is really hard to tune.
• If you have exhausted the amount of network bandwidth then you should be thinking about moving processing close to the service.
• If you have exhausted the amount of computational power, either processing or disk, then you should be thinking about replicating the service to scale out across the network
• If clients are having trouble but you've maxed out neither your network nor computational power, then you probably need to go back and fix your throttles.

http://blogs.sun.com/jonthecollector/entry/size_matters
Size Matters (Page last updated June 2007, Added 2007-06-28, Author Jon Masamitsu, Publisher Sun). Tips:

• If the application tries to allocate object AAA and there is not enough free space in eden for the allocation, a garbage collection usually occurs.
• The garage collector follows this strategy: 1. Allocate out of the young generation; 2. Possibly allocate out of the tenured generation; 3. Collect the young generation; 4. Possibly collect the tenured generation; 5. Try something else.
• If an application tries to allocate object AAA and AAA is larger than eden then the following strategy is followed: 1. Allocate out of the young generation; 2. Possibly allocate out of the tenured generation; 3. Collect the young generation; 4. Possibly collect the tenured generation; 5. Try something else (e.g. clear soft references, etc).
• If you have large objects try to make your young generation large enough to hold plenty of them (10's would be good, 100's would be better).

Jack Shirazi Back to newsletter 079 contents