Mr Chung,
On Thu, 9 May 2002, Kin-Man Chung wrote:
> 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?
Good idea, but I think it would be hard to accomplish as presented. Look again
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.
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 look at what we have to do in the "finallies" method, we have essentially
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()?
If we could do the "popBody()" calls out of order, say after all the "release()"
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.
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.
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" variable,
merit more thought. There may be a way to use it.
What do you think?
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
