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 106 contents

http://www.ddj.com/java/219401061
G1: Java's Garbage First Garbage Collector (Page last updated August 2009, Added 2009-09-29, Author Eric J. Bruno, Publisher DrDobbs). Tips:

• When speaking about garbage collection algorithms, parallelism describes the collector's ability to perform its work across multiple threads of execution. Concurrency describes its ability to do work while application threads are still running. A collector can be parallel but not concurrent, concurrent but not parallel, or both parallel and concurrent. The CMS collector is parallel and partially concurrent as it pauses application threads at many points (but not all) to do its work. The G1 collector is fully parallel and mostly concurrent.
• From JDK6 update 14, the G1 collector is available. In update 14, it can be enabled using -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
• To suggest a GC pause time goal of nor more than 50 ms in every second with the G1 collector, use -XX:MaxGCPauseMillis=50 -XX:GCPauseIntervalMillis=1000.
• With G1 the size of the young generation can be specified explicitly to alter evacuation pause times, e.g. -XX:+G1YoungGenSize=512m (for a 512 megabyte young generation).
• Use -XX:+G1ParallelRSetUpdatingEnabled -XX:+G1ParallelRSetScanningEnabled to utilise G1 optimally - but in JDK 6 update 14 this can produce a race condition and result in an error

http://kirk.blog-city.com/simple_logging_tip.htm
Simple logging tip (Page last updated September 2009, Added 2009-09-29, Author Kirk Pepperdine, Publisher Pepperdine). Tips:

• Aggressive logging can easily cause a performance problem
• Using a log.debug(- some code that needs evaluating to make a string -) statement for logging means that the code to produce the string is evaluated whether or not the log statement is emitted. This can produce significant amounts of unnecessary objects and lead to performance issues.
• Wrap log statements in if statements (if ( debug ) log.debug(...) ) to avoid unnecessary object creation and code evaluation.

http://blogs.sun.com/mobility_techtips/entry/code_destroyapp_code_is_your
destroyApp() Is Your Friend (Page last updated September 2009, Added 2009-09-29, Author Vikram Goyal, Publisher Sun). Tips:

• The MIDlet record entry method recordStore.addRecord() is atomic
• The destroyApp() method gives you a way to complete unfinished items before it actually closes the MIDlet. If called unconditionally you must close the MIDlet. But if the closing is not unconditional, and if you are in the middle of the writing process, you can throw the MIDletStateChangeException to finish the writing process.
• If the MIDlet destroyApp() method is called unconditionally and you are in the middle of writing, you need to rollback any data that has been written.
• [Article provides a canonical implementation of the MIDlet destroyApp() method that handles partially written records for both conditional and unconditional calls of destroyApp()].

http://www.javaspecialists.eu/archive/Issue176.html
The Law of the Xerox Copier (Page last updated September 2009, Added 2009-09-29, Author Heinz M. Kabutz, Publisher The Java Specialists' Newsletter). Tips:

• An immutable class (e.g. String) is defined as one where: State cannot be modified after construction; All the fields are final; and the 'this' reference does not escape during construction.
• To minimize concurrency issues, instead of changing objects return a new copy containing the changes.

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=121
Software Longevity Testing (Page last updated September 2009, Added 2009-09-29, Author Steven Woody, Publisher BetterSoftware). Tips:

• Few test plans include longevity testing apart from memory leak testing or letting the software run for a couple of days. Longevity testing (also known as soak testing or endurance testing) looks for software problems that appear only after an extended operational time. These problems fall into two broad categories: problems due to the passing of time and problems due to cumulative usage.

• Users and systems will not necessarily reboot their systems periodically - assume the opposite and test accordingly.
• Software run for extended periods can drift in accuracy.
• Timeouts and expirations that need to be tested for include user session timeouts, firewall session timeouts, ARP tables and MAC address tables aging out, routing tables expiring, SIP registrations renewing, DHCP leases renewing, DNS mappings expiring, age-based passwords expiring, automatic maintenance activities such as daily virus scans, nightly database resynchronizations, weekly database backups, and monthly software patches or upgrades.
• Forgotten software licenses tend to expire at the worst possible time. Gentle warnings should be given weeks in advance of a software license's expiring. Software applications that depend on the software license need to handle the expiration gracefully.
• Longevity testing should include tests of long busy periods (soak testing) as well as long idle periods (quiescent testing).
• All date and time software should be tested for near-term rollover dates and times such as the one-hour adjustment for daylight saving time (in fall and spring) and February 29 (Leap Day, occurring mostly every four years). Systems using UTC or NTP need to contend with an extra leap second being added (23:59:59, 23:59:60, 00:00:00) yearly in June or December, as needed. Longer-term rollover dates include the GPS system seconds reaching 999,999,999 on September 14, 2011, and the GPS week number rollover on April 7, 2019. The most well-known operating system calendar rollover is the Unix 32-bit time overflow that will occur on January 19, 2038.
• Reboot the software after each rollover to verify that the system will boot up, initialize, and then operate correctly
• The most common resource exhaustion procedural mistake is letting the system fill up: either letting some file get so big that there is no more disc space for it, or letting the transaction audit trail get so large that no new log records can be written .
• Resource exhaustion problems often creep in on resources that are not monitored, including inodes, file handles, sockets, process threads, and data buffers and queues. Longevity testing attempts to find resource exhaustion bugs in as short a time as possible
• Longevity testing should look for overflows (like integer overflows) and reentrant code bugs (bugs not showing up until the second run of code or incorrectly initialized code)
• Techniques for accelerating logevity testing include increasing all resource and data usage to maximums, preset counters and values to close to exhaustion or rollover, and to pre-consume resources.
• For longevity testing, start early, put the system under heavy load, continuously monitor the performance, and let it run for days, months, or years.

http://www.developer.com/java/ent/article.php/3832961/Performance-Improvement-Bigger-and-Better.htm
Performance Improvement: Bigger and Better (Page last updated August 2009, Added 2009-09-29, Author Robert Bogue, Publisher Gamelan). Tips:

• The most coarse metrics (e.g CPU utilization) are the first step on looking at the problem to determine what it may be. By monitoring these metrics at each server in a system it is usually possible to determine the key bottleneck for a system.
• One way to locate the cause of a performance problem is to change the circumstances so that the problem goes away or makes it worse.
• You can take lots of production data and place it on a development system that is less powerful than the production system so that a smaller load will cause the performance problems to crop up.
• If you can't locate a bottleneck but there is slowness then you're probably on the hunt for a remote calls and latency, such as active directory or DNS misconfigurations.
• In performance improvement the art is knowing what to test, the science is knowing how to test.
• Removing any one problem or any one bottleneck won't necessarily resolve your performance issues completely. Tuning is usually an iterative process.
• Improved session state management and lots of useful caching can provide dramatic improvements in performance.
• Techniques for splitting workloads include: separating independent application functionality onto separate machines; load balancing; multiple front-end webservers; multiple back-end database servers.

Jack Shirazi Back to newsletter 106 contents