JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning 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: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 127 contents

http://www.javaspecialists.eu/archive/Issue191.html
Delaying Garbage Collection Costs (Page last updated April 2011, Added 2011-06-28, Author Dr. Heinz M. Kabutz, Publisher The Java Specialists' Newsletter). Tips:

• Calling System.gc() is not generally advised as it is usually a performance tune that quickly becomes obsolete and even bad, but can be appropriate in very specific situations where you know a phase of object creation has completed and you have time for GC to process - e.g. after initialization but before full scale processing starts.
• ThreadMXBean.getCurrentThreadUserTime() provides a mechanism to measure CPU time used by the thread, rather than elapsed time.
• Having a huge (young genration) heap to avoid garbage collection completely is an unusual strategy but could work in some specialized applications.
• -XX:+AggressiveOpts is an interesting experimental option that provides a current "aggressive" set of JVM parameters that might work for your app - but note these options can change with any JVM version. You can use -XX:+PrintFlagsFinal to diff with and without the -XX:+AggressiveOpts to see what that flag sets for your JVM version.
• The Integer objects that are cached are from -127 to 128 by default, but the upper bound can be changed using -Djava.lang.Integer.IntegerCache.high=NEWVALUE or -XX:AutoBoxCacheMax=NEWVALUE

http://mailinator.blogspot.com/2011/05/notes-from-programming-leap-to.html
The Programming Leap to Multithreading (Page last updated May 2011, Added 2011-06-28, Author Paul Tyma, Publisher mailinator). Tips:

• A synchronous 1-thread per request model can handle a higher throughput than an asynchronous shared queue handing off to a worker pool model
• Concurrency is really really really difficult to get right. Avoid shared data. Use use java.util.concurrent.*
• Use the actor model to avoid many concurrency problems - no shared data avoids problems with visibility, ordering and race conditions.
• HashMap has a concurrency race condition that can result in an infinite loop in normal operation, so should not be used unguarded in multi-threaded code. But routinely is. It does say it's not thread-safe, so it's not HashMap's fault.

http://www.shunra.com/shunrablog/index.php/2011/05/23/apm-is-broken-or-at-least-it%e2%80%99s-not-delivering-on-its-promise-of-improving-performance/
APM is Broken (Page last updated May 2011, Added 2011-06-28, Author Todd DeCapua, Publisher Shunra). Tips:

• Over 80% of large and mid-sized organizations worldwide have made multi-million dollar investments in Application Performance Management solutions.
• In a show-of-hands at Interop 2011 98% of attendees agreed that their Application Performance Management solutions was working "less than fair" (out of options working: well/fair/less than fair).
• According to NIST four out of every five dollars of the total cost of ownership of an application are spent and directly attributable to finding and fixing problems post-deployment.
• Application Performance Management (APM) capabilities cover five functional dimensions (according to Gartner): End-user experience monitoring; Application runtime architecture discovery and modeling; User-defined transaction profiling; Application component deep-dive monitoring; Application data analytics.
• Most Application Performance Management solutions generate too many alerts.
• The complexity of an Application Performance Management implementation into an enterprise prohibits widespread adoption of a solution.
• Enterprise IT decision-makers are aligned more with Infrastructure rather than Applications, so the solutions adopted tend not to be application-centric.
• A proactive approach to building performance into the entire development lifecycle is recognized but not yet pervasive - budget and resources are not yet aligned with the need.
• Issues with the performance of business-critical applications can cause deterioration of an organization's business performance. Slow or not readily available applications that support key business processes can cause revenue loss, and decline in customer satisfaction, employee productivity or brand reputation.

http://blog.dynatrace.com/2011/04/20/the-top-java-memory-problems-part-1/
The Top Java Memory Problems - Part 1 (Page last updated April 2011, Added 2011-06-28, Author Michael Kopp, Publisher dynatrace). Tips:

• Memory leaks are the easiest memory issue to track down as you can look at trending or histogram dumps (from jmap -histo <pid>).
• A thread local variable is referenced by its thread and as such its lifecycle is bound to it. In most application servers threads are reused via thread pools and thus are never garbage collected. If the application code is not carefully clearing the thread local variable you can easily get a memory leak.
• Static fields holding collections that can be added to are a frequent source of memory leaks - because the class is never garbage collected, neither is the collection held by the static variable, so unless it is being manually cleaned, objects added to teh collection will typically stay for the lifetime of the application.
• A common memory leak is where an object is used to create derived data, e.g. a 'child' of the object, and the child object retains a reference to the main object (e.g. XML document parsing where nodes retain a reference to the document). You may think the main object is collectable, but the child keeps it alive as long as you refer to the child.
• JNI can create local or global references to objects. The global references are never cleared until explicitly done by JNI code - this can lead to a memory leak.
• If equals/hashcode violate the required contract (hashcode should not change over the lifetime of an object, and if two objects are equals they must produce the same hashcode), this can lead to a memory leak if they are used in hashed collections (like HashMap).
• While an object continues to be strongly referenced, it's class and classloader (and all classes referenced by the classloader) cannot be garbage collected. This can lead to a memory leak.
• If you dynamically create classes, the classloader used (e.g. the current classloader) will continue to reference those classes until the classloader is garbage collected - which is a difficult to diagnose memory leak in perm generation.
• A static threadlocal referring to the classloader containing the static will never be garbage collected, so leading to a memory leak.

http://www.informit.com/articles/article.aspx?p=1693533
The Road to Effective Capacity Management (Page last updated March 2011, Added 2011-06-28, Author Larry Klosterboer, Publisher informIT). Tips:

• Capacity management has the most promise for immediately saving your organization money - effective capacity management can easily save 20-30 percent of your current hardware and software budget.
• Each category of resource you wish to manage must be listed as a separate capacity pool - but you should only manage those things that return real value by managing them (ignore resource pools that are already effectively managed or that would not produce a cost effective saving if managed).
• Collect technical level details for each capacity pool. Disk allocation and utilization can be gathered from the SAN management tools. Server CPU and memory utilization might come from various operating system utilities or from your monitoring tool set. Network packet rates and utilization numbers can come from a network management solution.
• Observe the trends in the data. For each capacity pool, document the trend over time so you can understand whether utilization of that pool is growing or shrinking.
• Once you have good trend data for each of your capacity pools, use trend data to make predictions for when capacity will be exhausted (or can be freed).
• The goal of a capacity plan is to avoid surprises such as running out of capacity at an inopportune moment but also to avoid purchasing and deploying more capacity than is needed.

http://java.dzone.com/articles/parallelism-dummies
Parallelism for dummies (Page last updated June 2011, Added 2011-06-28, Author Giorgio Sironi, Publisher JavaLobby). Tips:

• multiple threads with shared memory and locks is a popular concurrency model which can cause failure in programs due to race conditions, starvation, deadlocks.
• multiple processes with no shared memory which communicate via explicit messages and are commonly juggled continuously in time-sharing by the OS is a heavyweight concurrency model.
• The actor model where actors substitute processes as the basic unit of computation is a more recent concurrency model that avoids many of the problems of from shared memory - but can be difficult to implement.
• Clustering (replicating components across multiple machines) is a cost-effective way to scale, and offers built-in redundancy. Stateless components can be replicated easily; replicating stateful components can be problematic.
• The time needed for an algorithm is divided into two parts, the sequential and parallel fractions. Parallelism can decrease the time needed for the Parallel fraction, but cannot do anything for the Sequential one. Tthe sequential fraction will never become shorter, no matter how many processors or machines you add.
• Static analysis is not enough in profiling; you must find out if a fraction of your code is large enough to gain significant performance from parallelizing it before parallelizing it.

Jack Shirazi Back to newsletter 127 contents