> I've been thinking and working on a possible fix for bug > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8290. The issue concerns > the often deep nesting of try/finally blocks that triggers a bug in the > JVM that result in bad JSP performance. The proposition is to limit the > number of try/finally blocks by marking what would be the try block as > started and then marking again when the finally block would be entered. This > bug is mostly evident if a JSP uses a lot of taglibs tags. > > More simply put, the proposition replaces code like this: > > public class JSPsomething { > <...> > > public void _jspService(HttpServletRequest request, HttpServletResponse response) > throws java.io.IOException, ServletException { > > <...> > try { > <TRY BLOCK 1> > > try { > <TRY BLOCK 2> > > try { > <TRY BLOCK 3> > } finally { > <FINALLY BLOCK 3> > } > > try { > <TRY BLOCK 4> > } finally { > <FINALLY BLOCK 4> > } > } finally { > <FINALLY BLOCK 2> > } > } finally { > <FINALLY BLOCK 1> > } > } > } > > > To be generated like this: > > public class JSPsomething { > <...> > > public void _jspService(HttpServletRequest request, HttpServletResponse response) > throws java.io.IOException, ServletException { > > try { > <...> > set_bit(1) > <TRY BLOCK 1> > > set_bit(2) > <TRY BLOCK 2> > > set_bit(3) > <TRY BLOCK 3> > > clear_bit(3) > <FINALLY BLOCK 3> > > set_bit(4) > <TRY BLOCK 4> > > clear_bit(4) > <FINALLY BLOCK 4> > > clear_bit(2) > <FINALLY BLOCK 2> > > clear_bit(1) > <FINALLY BLOCK 1> > } finally { > doFinally() > } > } > > > doFinally() { > if_bit_set(3) > <FINALLY BLOCK 3> > if_bit_set(4) > <FINALLY BLOCK 4> > if_bit_set(2) > <FINALLY BLOCK 2> > if_bit_set(1) > <FINALLY BLOCK 1> > } > } > > > On a flow control view point both are identical, but the second one has the > advantage of not needlessly nesting try/finally blocks, so it bypasses the > bug of the JVM. I did a patch that is relatively "fresh", so I can't provide > any hard benchmark to demonstrate the performance gain of the approach. But > our initial results did show some very encouraging performance results. > With a JSP with 100 taglibs, the "old" code triggered the bug in the JVM > that resulted in frequent JVM stall from 5 to as much as 45 seconds. the > "new" code did not show this behaviour. Next week I'll be able to use > JMeter to load test the "new" code and compare it the the "old" code. > > Comments or suggestions are welcome.
This looks like a good idea to me (Kin-Man is not there this week, so it's not an expert opinion). I would see that kind of change going into Jasper 2, though. Do you think you can prepare a patch against that version ? Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
