Denis,
Glad that you agree. About the timing for the patch, I think now is OK.
Jasper 2 is fairly stable and the only bug that may interact with our
fix is 4964 and I already have a fix for it; but am hold off committing
it because struts depends on this bug, and my fix would break it! :-(
Now down to details. :-)
Since a popBody is always followed by a release, it would be simpler
to have each stack element consists of two entries:
1. the tag, and
2. the state: 0 - release only
1 - popBody and release.
That way we only need to do one push per tag handler. Of course, all
tags would get state 0 first, and some of them would change to state 1
later.
For efficiency we can use two separate arrays for implementing the
stack: one for holding the tags, the other for keeping track of the state.
The code generated would be like:
stackIndex = -1;
...
++stackIndex; // Entering a tag
MyTag mt = new MyTag();
tagStack[stackIndex] = mt;
stateStack[stackIndex] = 0; // state 0
if (_jspx_eval_myTag != EVAL_BODY_INCLUDE) {
stateStack[stackIndex] = 1;
...
}
...
--currentIndex; // Exiting a tag
This way, the size of the stack is the maximum number of nesting of the
tags, which should much smaller than the number of tags in the page.
Such information is easy to collect in Jasper 2, which can be
done either in Validator.java, or we have a separate pass whose sole
purpose is to collect info such as this.
- Kin-man
> Date: Thu, 16 May 2002 23:16:15 -0400 (EDT)
> From: Denis Benoit <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by
Jasper2
> To: Kin-Man Chung <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> MIME-version: 1.0
>
>
> > Now you mentioned the use of an array to hold tag objects, I have
> > another idea. Why don't we use a stack to simulate the runtime state?
> > Each stack entry would have a tag object and a state. State 0 means
> > call release() only, and state 1 means call popBody() and then release().
> > We push an entry onto the stack when we enter a tag body, and pop it
> > when we exit the body. We change the state on the stack top when we do
> > a pushBody. When an exception is thrown, we just need to pop the entries
> > from the stack to decide what to do. For efficiency, we can use an
> > array to simulate the stack, and its size would be the number of nesting
> > of the tags.
> >
> > I think this is quite simple and faster. What do you think?
>
> Yes! Yes!
>
> In my last e-mail, I mentionned that there is only two actions that we need
> to do in the "finallies". This is:
>
> 1) do a release() on a Tag
> 2) do a popBody()
>
> We could push on the stack in this order:
>
> Either:
> 1- A tag
> 2- The Action identifier for release (a Constant representing
"release()")
> Or:
> 1- The Action identifier for popBody (a Constant representing
"popBody()")
>
>
> Now the "finallies" code look like this:
>
> While stack is not empty:
> Pop an action
> If action is RELEASE then
> pop a Tag
> Do a Tag.release()
> Otherwise /* Action is assumed to be POPBODY */
> do a popBody()
>
> So the "finallies" could very well be "inlined" because it would be short.
>
> The other modification would be when we begin the "pseudo" finally block. At
> that point we have to remove from the stack what was pushed at the begin of
> the "pseudo" try block. If we do a popBody() in the "finally", then we must
> pop one element. If we do a release(), we will pop two elements.
>
> In the event of an exception anywhere in the page, the stack would contain
> only the actions that must be performed in the order to be performed. Your
> solution is clean, efficient and simple!
>
> The stack could very well be an Object[], but if we must rely on arrayCopy(),
> to extend the array periodically, would it be really much more efficient than
> using a plain Stack object? After all, this is the way a Stack is implemented
> by the JDK itself. On the other hand, we know the lower and upper bounds of
the
> stack. Each tag will need to be pushed at least once for the "release()" and
> the action identifier will need to be pushed too (so we push two times the
> number of Tags in the page). And maybe we will need to push once more for a
> "popBody()" (so one more time to indicate the action).
>
> This would give us an array of size 2 to 3 times the number of tags in the
page.
> I think it would be more efficient to allocate an array of 3 times the number
of
> tags and save us the occasional overhead of arrayCopy() calls to extend the
array.
>
> Now, I see two ways to determine the size of the array. Either, after
> generating the _jsp_service() method, the class Generator could produce the
> declaration of the array because at this time, it would know what was the
> "upper" index in the array. But it would not be very elegant. The variables
in
> the generated class are expected to be put at the top of the generated java
> file, not in the middle between method declarations.
>
> The other option would be to be able to retrieve the number of tags in the
page
> from the PageInfo object. This would be cleaner, because we could then
declare
> the array at the top of the generated java file.
>
> In a word I'm very much willing to produce such a patch. But, we have to
think
> if now is the appropriate time. Jasper2 is in the process of being
stabilized,
> shouldn't we wait for the current bugs to be fixed, and once a stable release
> is ready for Tomcat, start an optimisation phase? This is your call, if you
> want it now, I could have such a patch ready for monday for your approval.
>
> Thanks!
>
> --
> Denis Benoit
> [EMAIL PROTECTED]
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
