Performance Refactoring to Reduce Garbage Creation(Advantage in tomcat 5)

The first enhancement to look at is Tomcat 5.0's memory-profiling tools. Tomcat 5 has been carefully optimized so that it produces less object garbage for the Java VM's garbage collector to have to clean up.




A typical problem with busy Java servers is that the server software constantly instantiates new objects, and when they're not needed anymore (typically, when a request ends), the objects are not reused but instead thrown out as garbage. The garbage collector must then find and reap all such objects to reclaim the memory they occupy. This takes time and CPU cycles to do, and in the meantime the whole JVM may be paused so that the garbage collector can finish its work. This means the requests currently in process must simply wait until the garbage collector is done, which makes the whole server slow down a little. Usually, this isn't a big problem because the garbage collector is pretty efficient at collecting garbage objects. But in some cases there is so much garbage being produced that it can't keep up, and eventually the amount of free memory gets low because there is a backlog of garbage objects using lots of memory. Or sometimes a web app creates very large objects that take the garbage collector longer to finalize and destroy, so the amount of free memory is lost in large chunks but isn't being replenished quite as fast.



Tomcat 5.0 has had many garbage creation (read performance enhancement) changes since Tomcat 4.1. Tomcat 5.0's single most important garbage-creation refactoring was the new request URI mapper. After some optimization profiling, Tomcat 4.1's request pipeline was found to create excess garbage while mapping a Connector's requests to the proper Container. For Tomcat 5, a whole new mapper was implemented that generates little or no garbage (lots of object recycling is going on in there), and thus Tomcat 5.0's request pipeline performs noticeably better than that of Tomcat 4.1. This also lowers the overall memory usage compared to Tomcat 4.1, which helps to prevent OutOfMemoryExceptions in the web apps it runs, and helps Tomcat 5 to scale higher vertically (i.e. higher scalability on a single machine).