tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kin-Man Chung <Kin-Man.Ch...@Eng.Sun.COM>
Subject Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by Jasper2
Date Thu, 09 May 2002 20:47:09 GMT

> Date: Wed, 08 May 2002 20:50:06 -0400 (EDT)
> 
> Mr Maucherat noticed that the patch do create a BitSet and a Vector, even for
> JSPs that don't have tags, I think it could be avoided if we did some kind of
> lazy initialisation.  My first, dumb, I confess! idea was to put the Vector
> and the BitSet as instance variables, but Mr Barker was quick to point out
> that it would cause thread problem.  My idea was then to have the patch mature
> and if everything was ok to do a second pass to optimize it.
> 

> -- 
> Denis Benoit
> benoitde@sympatico.ca
> 

Denis,

One way to get rid of BidSet is to keep the state of things that needs to
be done in the (now virtual) finally block.  Since the try blocks are
properly nested, it is sufficient to increment the state when entering
a try block, and to decrement it when exiting a try block.  Something
like:

	int state = 0;
	// try {	// 1st try
	    ++state;
	    ...
	    // try {	// 2nd try
	        ++state;
	        ;;;
	    // }	// end of 2nd try
	    --state;
	    // try {	// 3rd try
	        ++state;
	        ;;;
	    // }	// end of 2nd try
	    --state;
	// }		// end of 1st try
	
Then in finallies, you can do

	if (state >= 1 && state <= 3) {
	    if (state == 2) {
	        // do finally for 2nd try
	    } else if (state == 3) {
	        // do finally for the 3rd try
	    }
	    // do finally for 1st try
	 }
	 
and so forth.  I think it would be faster than using bitset.

To avoid using a Vector, you can try inlining finallies in _jspService
method.  The compiler needs to keep track of what needs to be done
at the finally blocks for each of the state, but we don't need to do
any of the Vector operations at all, a big performance gain.  If you
insist on having a separate finallies, then you can still pass all the
objects it needs to it as arguments.

In is now possible in jasper2 to scan the nodes for the page and collection
infos on the page (that's what PageInfo class is for), and the compiler
only needs to generate codes that is really necessary.  For instance,
the generation of the method addTagToVector can be ommited when there is no
custom tag action in the page.  I can add such info in PageInfo, now
that there is a use.

Comments?
	


--
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