You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Garrett Serack - x3 <gs...@timesthree.com> on 2000/09/21 15:55:25 UTC
Java code generation tomcat JSP's
I've run into a couple of snags with Tomcat 3.1, I've got a couple of
complex JSP pages which are starting to run rather large, and make extensive
use of in-house custom Tags.
The Code that Tomcat is generating is MASSIVE. 441k .java / 75k .class file.
wow.
I'm starting to run into VerifyErrors on the class itself, after it has been
compiled. This behavior has been noted as a bug on Sun's bug tracking
system. (Bug ID: 4211181 (verifier) VerifyError using custom class loader
(http://developer.java.sun.com/developer/bugParade/bugs/4211181.html) )
Now in a panic effort to solve our problem, we first upgraded Solaris to
jdk1.3. No help. Then we moved to Tomcat 3.2b4, and the code generation was
better, and it helped.
Now I looked at the code Tomcat generates and while 3.2b4 's is better,
(less introspection to set properties from tags) It still looks rather
wasteful. And there is no object pooling of the tag resources themseleves.
This is going to lead to a severe problem in scaling apps larger.
So, I guess my questions are :
1. Is anyone looking into the use of taglibs, and the code that is generated
to use them? How about adding object pooling into the code to re-use the
instances of the tags more?
2. I've been wondering if the massive amount of try/catches are neccasary in
the code generation, could this not be done slightly higher up and catch
with less fine granularity? This would significantly impact the speed of
execution and the .class file complexity ( hopefully skirting Bug ID:4211181
)
3. is there a way to make Tomcat not emit the comments into the generated
java files? I went thru and stripped out the comments from a couple of the
files, and they dropped about 130K out of 440K. I know, the comments don't
affect code size, and the JSP's don't recompile all the time, so this should
not affect production speed at all, but I do have to recompile the JSPs tons
of times a day, and anything I can to to shave off a second or two makes me
happy.
4. There are a large number of identical
if( xxx == yyy )
throw new JspException( "really reallyreally reallyreally
long string");
type of expressions int the generated code. With all these potential object
creations in the code it might be much much more simple to instantiate the
Exception object at the beginning of the code, and throw it when the fit
hits the shan.
if( xxx == yyy 0
throw thePrebuiltException;
Much less code in the course of the generated java file...
Anyhoo, just my 2c + tax....
Garrett
Garrett Serack
Software Development Consultant
gserack@timesthree.com
403-569-7012
Re: Java code generation tomcat JSP's
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
There's a couple of things in there that can help you reduce the code size.
There is an init param that stores all the template text in a separate file.
That way the string constants all don't show up in the generated code. I don't
remember the name of the init param, please look it up. Also I did this really
long time back and I'm not sure if every change to Jasper was tested with this
init param on and off. The default is that the template text are emitted as
string constants.
If you don't like the comments that give location info for IDEs and other
generated code readers, you can add another init param which is checked before
emitting the locus info. This should be a very small change.
Otherwise thanks for making a list of things tat could be canged for
performance. I don't work on this stuff anymore but if I do get a spare day or
two and no one beats me to it, I'll try to take care of your the items on your
list.
Garrett Serack - x3 wrote:
> I've run into a couple of snags with Tomcat 3.1, I've got a couple of
> complex JSP pages which are starting to run rather large, and make extensive
> use of in-house custom Tags.
>
> The Code that Tomcat is generating is MASSIVE. 441k .java / 75k .class file.
> wow.
> I'm starting to run into VerifyErrors on the class itself, after it has been
> compiled. This behavior has been noted as a bug on Sun's bug tracking
> system. (Bug ID: 4211181 (verifier) VerifyError using custom class loader
> (http://developer.java.sun.com/developer/bugParade/bugs/4211181.html) )
>
> Now in a panic effort to solve our problem, we first upgraded Solaris to
> jdk1.3. No help. Then we moved to Tomcat 3.2b4, and the code generation was
> better, and it helped.
>
> Now I looked at the code Tomcat generates and while 3.2b4 's is better,
> (less introspection to set properties from tags) It still looks rather
> wasteful. And there is no object pooling of the tag resources themseleves.
> This is going to lead to a severe problem in scaling apps larger.
>
> So, I guess my questions are :
> 1. Is anyone looking into the use of taglibs, and the code that is generated
> to use them? How about adding object pooling into the code to re-use the
> instances of the tags more?
>
> 2. I've been wondering if the massive amount of try/catches are neccasary in
> the code generation, could this not be done slightly higher up and catch
> with less fine granularity? This would significantly impact the speed of
> execution and the .class file complexity ( hopefully skirting Bug ID:4211181
> )
>
> 3. is there a way to make Tomcat not emit the comments into the generated
> java files? I went thru and stripped out the comments from a couple of the
> files, and they dropped about 130K out of 440K. I know, the comments don't
> affect code size, and the JSP's don't recompile all the time, so this should
> not affect production speed at all, but I do have to recompile the JSPs tons
> of times a day, and anything I can to to shave off a second or two makes me
> happy.
>
> 4. There are a large number of identical
>
> if( xxx == yyy )
> throw new JspException( "really reallyreally reallyreally
> long string");
>
> type of expressions int the generated code. With all these potential object
> creations in the code it might be much much more simple to instantiate the
> Exception object at the beginning of the code, and throw it when the fit
> hits the shan.
>
> if( xxx == yyy 0
> throw thePrebuiltException;
>
> Much less code in the course of the generated java file...
>
> Anyhoo, just my 2c + tax....
>
> Garrett
>
> Garrett Serack
> Software Development Consultant
> gserack@timesthree.com
> 403-569-7012
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
Peace, Anil +<:-)
Re: Java code generation tomcat JSP's
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Alex Chaffee wrote:
>
> > 3. is there a way to make Tomcat not emit the comments into the generated
> > java files? I went thru and stripped out the comments from a couple of the
> > files, and they dropped about 130K out of 440K. I know, the comments don't
> > affect code size, and the JSP's don't recompile all the time, so this should
> > not affect production speed at all, but I do have to recompile the JSPs tons
> > of times a day, and anything I can to to shave off a second or two makes me
> > happy.
>
> The comments are useful for debugging, at least theoretically.
The help isn't just theoretical. I understand that there are a couple of IDEs
(Forte is one) that actually scan those comments and uses them in their JSP
debuggers to help you find where the original error is.
There is also a Java Specification Request (#45) under way with the goal of
supporting a "source line map" concept when non-Java languages are translated into
Java and then into class files. JSPs are a prime use case for that kind of thing
to be done portably.
> Alex Chaffee mailto:alex@jguru.com
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: Java code generation tomcat JSP's
Posted by Alex Chaffee <gu...@edamame.stinky.com>.
I'm all for making the generated code cleaner, but I don't think
anyone is working on that specifically right now. I'm sure any work
you do (e.g. putting more code into the superclass or helper classes,
or using object pools) would be greatly appreciated. (Note
org.apache.tomcat.util.SimplePool for a simple thread-safe object pool
base class.)
One comment:
> 3. is there a way to make Tomcat not emit the comments into the generated
> java files? I went thru and stripped out the comments from a couple of the
> files, and they dropped about 130K out of 440K. I know, the comments don't
> affect code size, and the JSP's don't recompile all the time, so this should
> not affect production speed at all, but I do have to recompile the JSPs tons
> of times a day, and anything I can to to shave off a second or two makes me
> happy.
The comments are useful for debugging, at least theoretically. I
wrote a patch that scans the generated Java source at runtime to find
out the line in the .jsp that the error occured, but I don't think I
ever checked it in because I didn't get anyone to test it with
non-javac-1.2 compilers :-(
Thus, if you do want to strip comments, make it a runtime option set
in server.xml somewhere.
--
Alex Chaffee mailto:alex@jguru.com
jGuru - Java News and FAQs http://www.jguru.com/alex/
Creator of Gamelan http://www.gamelan.com/
Founder of Purple Technology http://www.purpletech.com/
Curator of Stinky Art Collective http://www.stinky.com/