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 Fri, 10 May 2002 01:41:40 GMT
See intermixed.

> Date: Thu, 09 May 2002 20:48:27 -0400 (EDT)
> From: Denis Benoit <>
> Subject: Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by 

> Good idea, but I think it would be hard to accomplish as presented.  Look 
> at your pseudo-code:
> > 	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
> You'll notice that both state 2 and state 3 have the value 2 assigned to the
> state variable.  What is complex here, is that it is hard to find a generic
> way to represent all the states possible.  Sometimes the states are nested,
> like the first with the 2nd and 3rd.  Sometimes the states follow one another,
> like the second and third.

I realized my mistake as soon as I sent it out.  :-) 

> But there is surely something to do.  Suppose we assign distinct values to
> the state variable at each step where we enter a "pseudo try" and a
> "pseudo finally".  Then, theoritically, it should be possible to determine
> in the "finallies" method, just by looking at the value of the state variable
> what remains to do.  The problem could be to do it in exactly the same order
> that would have been done if the page would have nested try/finally clauses.

If we have distinct values for each state, theorectically we can implement
a state transition machine in the finallies.  Something like the following.

	while (state > 0) {
	    switch (state) {
	    case 0: ...
	        state = 3; break;	// goto state 3
	    case 1:
	        state = 13; break;	// goto state 13
	    case 10: ...
	        state = -1; break 	// stop
This way we can specify any sequence we want.  Of course there are various
optimizations that one can do here, but I won't go into them here.

> If we look at what we have to do in the "finallies" method, we have 
> two types of method call.  Either the "popBody()" or the "release()" of a Tag.
> I'm certainly not expert enough with the JSP specs to take a decision.  Is it
> critical that we call the "release()" of the tags in the proper order, if all
> what's left to do is "release()" calls?  What about the popBody()?

popBody() simulates popping stacks, and has to be called in order.

> If we could do the "popBody()" calls out of order, say after all the 
> have been called, then the case of the "popBody()" is easy to deal with.  We
> just have to increment a counter for each "pushBody()" calls and decrement
> it after each "popBody()" calls.  In the "finallies" method we only have to
> call "popBody()" the number of times the value of the counter.  If so, the
> state variable would only to have to represent the different combinations that
> the tags "doStartTag()" have been called and if their respective "release()"
> have been called.

Unfortunately we cannot call release() before calling popBody(), because
popBody() may use resources released by release().  (I'll need to check

> I'm a little cautious about "inlining" the "finallies" method, because of
> java's 64K per method limitation.  One of the first pass of my test JSP did
> generate over 64K in the _jsp_service method, so it generated an "Invalid
> branch" exception or something named like that.  Once I removed a few tags,
> the page worked fine.  It's easy to bypass by "JSP include", but some people
> might find the message cryptic (it is!), to determine what's exactly the
> problem.  The _jsp_service method can be really long, even without the
> "finallies" being inlined.  That's why I had created a new method.

There maybe other ways to branch out part of the code in _jspService to
a method.  I am considering moving the body of a tag that does not have
scriptlets out; but that's just a thought at this moments.

Even if we do keep finallies, it may worth looking into passing all the
necessary objects as arguments to it, instead of putting them in a Vector,
at least for the case with samll number of states.  I think VM spec allows
256 arguments to a method.  :-)  We want to avoid "unnecessay" codes in
the main flow, but can afford to work harder when exceptions occur.

> Your idea of getting information from the PageInfo is certainly welcome.  This
> way we could prevent the creation of the "finallies" method and
> "addTagToVector".  We could even replace the Vector by an Array that could be
> allocated to the proper size at the start of the method.  It would prevent to
> have to cope with the expansion of a Vector.  Your idea of the "state" 
> merit more thought.  There may be a way to use it.

Collecting information to PageInfo requires a speparate pass prior to
code generation; but is certainly worth looking into.

> What do you think?
> -- 
> Denis Benoit

- Kin-man

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message