tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Benoit <benoi...@sympatico.ca>
Subject Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by Jasper2
Date Fri, 10 May 2002 03:02:34 GMT
Kim,

On Thu, 9 May 2002, Kin-Man Chung wrote:

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

Yes, that could be some thing to implement, when "generating" the code for a
state we have to know two things, the state itself, and the next state, it
may very well be possible.

Thinking about it, I think this is a feature that we could take advantage from.
Whenever we hit a state, the next state is determined and so on.

The more I look at it, the more it looks like a state machine.  Then, why not
implement it as a regular state machine in an array?  We could build a static
array at compile time, and just modify a state variable at run time that
represent the index in the array.  Then, if an exception occurs, we would only
have to apply the state to the static array to find out what we have to do.

I definitively need to think more about it, but it seems that we have something
here.

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

What about keeping a reference to the elements in an array?  Assignment to
an array element is not very costly.  We could even use the array elements
themselves instead of creating distinct variables for each tag.

If we do it this way, it can very well pave the way to reuse elements in
the same page.  Whenever we call "release()" on a Tag, instead of allocating
a new tag of the same type, we could reuse the tag, no?  I thought that the
specs allowed optimization of this sort?

If we have an array of tags, then the array of the state machine begins to
take form.  We could have "four columns" in the array (either objects to
hold the 4 data elements, or four distinct arrays).

The index of the array would be the state, the first "element of the row"
would be the next state (-1) for done.  The second "element of the row"
would be the action to perform, either "release()" or "popBody()", and
the last "element of the row" would be the index in the Tag array to apply
the action to (only meaningful for "release()").

The state array is "final static", built at compile time and never modified
for a given JSP, so thread safe.  The finallies method would only have to
loop thru the states and apply the action to the tags.

I need to think more about it, but it's starting to take form.

What do you think about it?

-- 
Denis Benoit
benoitde@sympatico.ca


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