Web Hosting Java, JSP, Tomcat 6, J2EE, Servlets, Struts, Jboss

Optimization 38: Last In, First Out On multithreaded

Optimization 38: Last In, First Out On multithreaded servers you will often encounter a performance requirement to pool server threads. Threads are expensive to create and destroy and therefore are ideally suited for object pooling. This is, however, a special pool with additional performance nuances. A Java thread can easily drag with it one MB of memory dedicated to required JVM data structures, as well as additional user-defined data. The last thread to hold the CPU has already gone through the work of loading its pages onto memory and a significant portion of its data and code segments onto the instruction and data cache. It would be foolish to throw all this work away. The thread pool should dole out threads in a last in, first out (LIFO) order. That way, we can have lots of threads in the pool (for a rainy day) but only a few that are truly active and using the CPU. This approach makes a much more effective use of the limited cache and memory space. A smaller number of active threads may fit all of their data and code into the cache. A LIFO thread pool keeps the cache and memory “warm.” Otherwise, if the pool gives equal opportunity to all its threads, we are likely to have a “cold start” for each thread from a caching and paging perspective. Some containers, such as a Stack and Vector, automatically lend themselves to the LIFO policy. The Stack won’t let you do it any other way, and the Vector should have elements added and removed from the back only (see Optimization 17). In a linked list, on the other hand, you could erroneously attach your threads to the end of the pool and remove from the front. That would be a costly caching and paging mistake. Page 142

Hint: If you are looking for very good and affordable webspace to host and run your j2ee hosting application check Virtualwebstudio j2ee web hosting services