I guess that is because, though IBM JDK handles too many blocks better than Sun JDK … it is still not as good as not having so many try-finally blocks. [Which is true if you look at the response time chart].

The diff between try-finally and a regular block is probably because of the “lookup table trashing” you are mentioning. But in case of Sun JDK, most of the time was spent doing GC. Atleast the verbose:gc showed that!

I guess we will get to know more when the Sun Engineers close the bug [hopefully they will post some details].

We had an application that worked fine on WebLogic. When we tried it with Websphere we found it was very slow indeed.

After much investigation we noticed it was because of a difference in the way WebSphere handled custom tag invocations in the generated servlet code (generated from a JSP).

WebLogic put all the custom tag invocations inside a single try/catch. Websphere instead put all the invocations in their own try/catch. I cannot remember the exact details but within a single method, there is a lookup table that is used to find some offset. The structure to hold these offsets can only hold something like 64 at a time. This is normally absolutely fine for a single method but in a servlet with the custom tags, Websphere was going above this limit.

The result was that it thrashed trying to move these offsets into the structure (you have to look at the VM code to see the precise reason for the thrashing and I cannot quite remember any longer).

Could this be what you are seeing?