On the other hand, the string manipulation API is enriched by StringBuilder, a faster replacement of StringBuffer. If you're doing any heavy text processing with handwritten StringBuffer operations, rush to port that code to StringBuilder. The new class is much faster simply because it's not synchronized (which is virtually never necessary). Even though Java's synchronization is pretty efficient, its overhead is still big for very simple methods, which is the case in most methods in the string classes. For compiler-generated code (from string concatenation operations) there's no need for manual change. Just recompile your code (with -source 1.5), javac will use StringBuilder instead of StringBuffer. Many core J2SE APIs (mostly in the lang, util, text, math, security, naming, and swing packages) are already optimized to use StringBuilder, so the new API should benefit even unchanged apps, and probably compensate the added costs of Unicode 4.0 compatibility.

Swing's new look&feels may have different performance traits than the old ones, but usually changes in LAFs are positive or little relevance performance-wise.

Overall, these are relatively small areas to worry about. Other major J2SE releases used to have more significant changes of existing APIs. Fortunately there isn't any revolutionary API update in Tiger. Still, since Tiger does include some changes in this category, I won't be surprised if somebody produces a microbenchmark yelling that half-a-dozen API methods became five times slower or faster in 5.0.

Implementation Changes
Sometimes one has to go back to the drawing board and rewrite a piece of software from the scratch. This doesn't happen when the old implementation was deficient. It happens when the old architecture won't accept new implementation enhancements. The most "memorable" event of this kind was Java 2 (J2SE 1.2), when the entire VM was dumped in the sea, and replaced with new code. We got brand new garbage collectors, JIT compilers, native interface, and virtually all the lower-level APIs (like Reflection and I/O) had to be reimplemented. The new architecture was much more powerful, flexible, scalable, evolvable - and of course, bigger, so most Java processes would suddenly consume a few additional megabytes to run the same code. Changes to this category will happen less often in more mature software, so J2SE 5.0 has only modest items in this category.

On the bright side, once a good architecture is laid out, many important implementation enhancements are often possible without major rewrites that risk stability and a new infestation of bugs. So this is also the category where we find most of the "free lunch" improvements, unless of course if you count the development effort of the JVM itself.

The JVM's low-level debugging and profiling interfaces: The introduction of the JVMTI and the deprecation of the old JVMDI and JVMPI interfaces (to be removed in J2SE 6.0). The old interfaces were always considered experimental and this move was expected. But like I said before, this only affects your performance in debugging, profiling, and monitoring tasks.

Java2D wasn't rewritten, but it got important implementation enhancements. The most exciting is a new OpenGL-based rendering engine that improves performance and unloads the CPU in machines with good OpenGL acceleration. This feature is still experimental; it will take some time (probably until J2SE 6.0) for Sun to work around driver compatibility issues and enable this by default. The other major enhancement is more immediately useful. Java2D is now much smarter about allocating images in video memory, and image-heavy applications may notice a much reduced heap usage and faster operations on images, especially when the app wasn't hand-tuned to compensate for the limitations of previous Java2D implementations.

The CDS (Class Data Sharing) is the only other major architectural change. It's not a full new JVM architecture, but it's still a significant change in one important aspect of the VM - how it manages the memory used by executable bytecodes. This is also a performance-oriented update, which should minimize loading time and per-process footprint.

In detail, CDS is the JRE's new ability to share memory used to load its core libraries between multiple JVM processes. At install time, the JVM converts the core APIs (from the 36Mb rt.jar) into a 12MB classes.jsa file under jre/bin/client. This .jsa file is much faster to load because (a) it's smaller, (b) parts of the classloading work are precomputed, and because (c) memory-mapped I/O is faster than the conventional file I/O used to read the rt.jar file. So CDS provides a good loading-time benefit even before accounting for sharing.

Classes containing mutable static variables can't be shared, so only ~50% of those 12MB are really shared. This should still deliver up to 6MB of memory savings per process, when multiple JVM processes run in the same host. There is no sharing of classes outside rt.jar, or of native code produced by the JIT compiler, so this initial implementation of CDS is still limited.

Benchmarking this is difficult. On a Windows platform, CDS makes your Java processes appear as if they're using more memory, since tools like the Task Manager make the process accountable for the entire size of the memory-mapped CDS file (12Mb) - even the shared part is apparently added to the 'Working Set' and 'Private Bytes' of all processes.

The best way to benchmark is by starting many processes and tracking the Free Physical Memory counter. I did this with 10 instances of Swing's Notepad demo. JRE 1.4.2_05 consumed 120MB, while JRE 5.0 consumed 92MB; an average savings of 3MB per process, which is huge for this small program (30% of the original 12MB per-process footprint). This tiny app doesn't exercise a lot of core APIs; more sophisticated apps should get closer to 6MB of savings.

GC Ergonomics - if you have a "need for speed" and lots of time in your hands, look no further than http://blogs.sun.com/roller/resources/watt/jvm-options-list.html for some comprehensive documentation of HotSpot's switches. There are more tuning options in your JVM than in some operating systems. But unless you work at Sun, you won't feel comfortable with most of these options. Too many are more useful to the people who build and support JVMs than for those using them. When I'm wearing my benchmarking hat, I love the fact that many of these options are available, but when I'm back at the office preparing an app deployment, I want 'java ClassName' to just work and deliver top performance - well, 'java -server -mxXXXm ClassName' is more realistic and still reasonable.

It's well known today that advanced JIT compilers like HotSpot or IBM JDK use dynamic profiling to learn which parts of your code deserve some special care (expensive optimizations). Why not apply the same solution to other aspects of the runtime like GC? This is the motto behind J2SE 5.0's recent improvements in automatic tuning. The JVM will "watch" an application's pattern of memory allocation and reclamation, and attempt to automatically tune its many internal parameters - sizes, thresholds, options - to provide the best performance out-of-the-box without requiring extensive testing or manual provisioning of those options.

Of course, the runtime can't guess everything. For example, games demand smoothness (no noticeable GC pauses), while servers usually favor raw throughput or scalability. Some level of manual tuning will always be important. The solution is to provide higher-level options like Tiger's new -XX:GCTimeRatio switch, allowing you to specify how much time (at most) should be spent in GC, with a single switch that mere mortals without a PhD in GC can understand.

Another related improvement is "server-class detection." This kind of idea is so simple, obvious, and useful that it's surprising how long it took for somebody to think of it. If neither '-server' nor '-client' are passed explicitly to the JVM, it will activate the HotSpot Server by default if the machine appears to be a "server." Right now the criteria is at least two CPUs, and at least 2GB of physical RAM. This is nice so Java doesn't run at half-power when inexperienced developers or administrators don't care to configure the VM even with the most trivial switches. Notice that this behavior is valid only for (32-bit) Solaris and Linux platforms. The 64-bit versions of Sun's JRE only implement the Server VM. On the Windows platform, the problem is that power users like software developers or gamers often use server-class systems, so it's better not to mess with the HotSpot Client default. Remember this before removing all the '-server' switches from your launching scripts.

Conclusion
There are substantial performance improvements in J2SE 5.0 to justify an upgrade even if you can't embrace the new APIs just yet that will render your code undeployable on older runtimes. Even better, there isn't any major risk of reduced performance due to rewritten or expanded features. Tiger should prove a trustworthy and performance-enhancing upgrade for application deployment, and this may be the best tactic to promote the new platform in more conservative environments.