tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
Subject Re: [PROPOSAL] Modification of the code generated by Jasper2
Date Mon, 29 Apr 2002 08:37:55 GMT
> 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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message