Re: [PROPOSAL] Tag pooling/reuse in Jasper 2

[peter lin]

I am definitely willing to put in time to test the patches. The
discussion has been great and covered all the concerns I had. With the
test pages I have, the 64K limitation forces me to break long pages into
several jsp files using both include directive and action include. In my
mind, it's good to break it up, since no one writing a servlet would
write a method exceeding 64K.

I'm biased towards improving JSP tag performance for concurrent
requests. For 1-4 connections, the performance is fine for pages with
80-150 tags. The same pages under 60+ concurrent requests takes a
performance hit due to GC as everyone already knows. Increasing the heap
size to 512 from the default results in increasing 2-3x the concurrent
requests. 

peter lin


Kin-Man Chung wrote:
> 
> I think it a good idea to limit the stacks to some reasonable value.  One
> easy way of accomplishing this is to add a tag object to the stack only
> when its stack has not reach its maximum size.
> 
> The neat thing about these two approaches is that they can both be
> implemented.  Once a tag object is obtained from the stack, the compiler
> can assign it to a local variable, and reuse that local variable for
> another tag handler in the same page, if needed.  The compiler has full
> control over when a tag object returns to the pool (stack).  Like
> Jan said, we intended to do such optimization for tags in iteration
> bodies.
> 
> I know Peter Lin is very interest in this area, and has tools and
> applications for measuring performance.  It'd be good if Peter can run
> them again after we put back our mods, and tell us what other areas that
> need to be worked on.
> 
> - Kin-man

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

Re: [PROPOSAL] Tag pooling/reuse in Jasper 2

[Kin-Man Chung]

I think it a good idea to limit the stacks to some reasonable value.  One
easy way of accomplishing this is to add a tag object to the stack only
when its stack has not reach its maximum size.

The neat thing about these two approaches is that they can both be
implemented.  Once a tag object is obtained from the stack, the compiler
can assign it to a local variable, and reuse that local variable for
another tag handler in the same page, if needed.  The compiler has full
control over when a tag object returns to the pool (stack).  Like
Jan said, we intended to do such optimization for tags in iteration
bodies.

I know Peter Lin is very interest in this area, and has tools and
applications for measuring performance.  It'd be good if Peter can run
them again after we put back our mods, and tell us what other areas that
need to be worked on.

- Kin-man

> Date: Sat, 01 Jun 2002 18:59:14 -0400 (EDT)
> From: Denis Benoit <[EMAIL PROTECTED]>
> Subject: Re: [PROPOSAL] Tag pooling/reuse in Jasper 2
> To: Tomcat Developers List <[EMAIL PROTECTED]>, Jan Luehe 
<[EMAIL PROTECTED]>
> MIME-version: 1.0
> Delivered-to: mailing list [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> X-Antivirus: nagoya (v4198 created Apr 24 2002)
> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> List-Post: <mailto:[EMAIL PROTECTED]>
> List-Subscribe: <mailto:[EMAIL PROTECTED]>
> List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> List-Help: <mailto:[EMAIL PROTECTED]>
> List-Id: "Tomcat Developers List" 
> 
> Hi,
> 
> For my part, I'm a little concerned about the second approach.  If there is
> a lot of pages with a lot of distinct tags; tags libraries are catching on
> fast; there may be a problem where Jasper would cache a lot of tags.  If there
> is a sudden burst of use of a given page, the stacks of the tags used by that
> page could grow significantly.  This memory would never be released.  If there
> was some way where the stack could throw away excess tags, then this approach
> would be very good indeed.
> 
> The idea I have in mind is the way the Apache 2.X HTTP server manages 
instances.
> When some instances have not been used for some time, it starts to shut them
> down until it reaches the "MaxSpareServer" number of instances.  This way,
> a sudden burst of use of the web server does not clog the process table or
> the memory of the machine.  This principle was very good.  Something similar
> could very well be as successfull with tag pooling.
> 
> This is just my .02
> 
> On Fri, 31 May 2002, Jan Luehe wrote:
> 
> > Kin-Man and I have been throwing around some ideas of how to support
> > tag pooling and reuse in Jasper 2.
> > 
> > According to the spec, only tags with the same set of attributes may
> > be reused (see JSP.10.1.1, p.163, "Lifecycle" section, item 3):
> >  
> >   [3] Note that since there are no guarantees on the state of the
> >   properties, a tag handler that had some optional properties set can
> >   only be reused if those properties are set to a new (known)
> >   value. This means that tag handlers can only be reused within the same
> >   "AttSet" (set of attributes that have been set).
> > 
> > This means that while the same tag handler instance may be used to
> > service these tags:
> > 
> >   
> >   
> >   
> >   
> > 
> > it may not be used to service
> > 
> >   
> > 
> > One of the ideas we have considered is to support tag reuse on a
> > per-page basis, without allowing tag handlers to be shared across
> > simultaneous page invocations. In this approach, each custom tag is
> > assigned a tag handler variable name at compile time, based on its
> > full name, its attribute names, and its nesting level (with respect to
> > tags with the same name and AttSet). According to this, the two
> >  tags in:
> > 
> >   
> > 
> >   
> > 
> >   
> > 
> > would be assigned the same tag handler variable name (both are at
> > nesting level 0 with respect to their tag "class"), whereas the two
> >  tags in:
> > 
> >   
> > 
> >   
> > 
> >   
> > 
> > would be assigned different tag handler variable names, because they
> > are at different nesting levels. All tag handler variables determined
> > in this fashion would be declared as (local) variables at the beginning of
> > the _jspService() method.
> > 
> > The advantages of this approach would be:
> > - No need for synchronization.
> > - Tag handler reuse is determined at compile time.
&

Re: [PROPOSAL] Tag pooling/reuse in Jasper 2

[Denis Benoit]

Hi,

For my part, I'm a little concerned about the second approach.  If there is
a lot of pages with a lot of distinct tags; tags libraries are catching on
fast; there may be a problem where Jasper would cache a lot of tags.  If there
is a sudden burst of use of a given page, the stacks of the tags used by that
page could grow significantly.  This memory would never be released.  If there
was some way where the stack could throw away excess tags, then this approach
would be very good indeed.

The idea I have in mind is the way the Apache 2.X HTTP server manages instances.
When some instances have not been used for some time, it starts to shut them
down until it reaches the "MaxSpareServer" number of instances.  This way,
a sudden burst of use of the web server does not clog the process table or
the memory of the machine.  This principle was very good.  Something similar
could very well be as successfull with tag pooling.

This is just my .02

On Fri, 31 May 2002, Jan Luehe wrote:

> Kin-Man and I have been throwing around some ideas of how to support
> tag pooling and reuse in Jasper 2.
> 
> According to the spec, only tags with the same set of attributes may
> be reused (see JSP.10.1.1, p.163, "Lifecycle" section, item 3):
>  
>   [3] Note that since there are no guarantees on the state of the
>   properties, a tag handler that had some optional properties set can
>   only be reused if those properties are set to a new (known)
>   value. This means that tag handlers can only be reused within the same
>   "AttSet" (set of attributes that have been set).
> 
> This means that while the same tag handler instance may be used to
> service these tags:
> 
>   
>   
>   
>   
> 
> it may not be used to service
> 
>   
> 
> One of the ideas we have considered is to support tag reuse on a
> per-page basis, without allowing tag handlers to be shared across
> simultaneous page invocations. In this approach, each custom tag is
> assigned a tag handler variable name at compile time, based on its
> full name, its attribute names, and its nesting level (with respect to
> tags with the same name and AttSet). According to this, the two
>  tags in:
> 
>   
> 
>   
> 
>   
> 
> would be assigned the same tag handler variable name (both are at
> nesting level 0 with respect to their tag "class"), whereas the two
>  tags in:
> 
>   
> 
>   
> 
>   
> 
> would be assigned different tag handler variable names, because they
> are at different nesting levels. All tag handler variables determined
> in this fashion would be declared as (local) variables at the beginning of
> the _jspService() method.
> 
> The advantages of this approach would be:
> - No need for synchronization.
> - Tag handler reuse is determined at compile time.
> 
> Disadvantages would be:
> - Tag handlers are not shared across multiple page invocations.
> - Does not work well with the proposed approach to remove the 64K limit,
> since a (possibly large) number of tag handlers would have to be
> passed as arguments to (sub)method calls.
> 
> --
> PROPOSAL:
> 
> An alternative proposal that we discussed would allow for tag pooling
> across page invocations, using a stack-based approach.
> 
> With this approch, each node representing a custom tag is assigned as one
> of its fields (at compile time) the name of a tag handler stack,
> based on the tag's full name and attribute set (tag's nesting level is
> ignored).
> All tag handlers in the same stack are intended to be shared among tags
> with the same name and attribute set.
> 
> For example, if this tag is encountered:
> 
>   
> 
> a tag handler for it is acquired from the stack named a_b_c_d. If
> this stack is empty, a new tag handler is created. When the tag
> handler is no longer in use, it is pushed back on the stack so it
> can be reused.
> 
> The tag handler stacks are declared as instance variables (and
> therefore won't need to be passed as arguments to any (sub)method
> calls implemented as part of the proposal to remove the 64K limit).
> 
> Notice that this approach is very similar to what was done in Tomcat
> 3.x, except that we would get rid of the TagPoolManager, which stored
> all the tag handler stacks (pools) in a hashtable (keyed by the pool
> name). This would save us a hash operation and synchronization (on the
> hashtable) on every stack lookup.
> 
> Note that this approach allows for optimizations in
> iterations. Instead of acquiring a tag handler from the appropriate
> stack and returning it to the stack in each iteration step, the tag
> handler could be acquired at the beginning of the iteration and held
> on to for the duration of the iteration.
> 
> If this sounds like a reasonable approach, I'll go ahead and provide a
> patch for Jasper 2 implementing it.
> 
> 
> Jan
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

[PROPOSAL] Tag pooling/reuse in Jasper 2

[Jan Luehe]

Kin-Man and I have been throwing around some ideas of how to support
tag pooling and reuse in Jasper 2.

According to the spec, only tags with the same set of attributes may
be reused (see JSP.10.1.1, p.163, "Lifecycle" section, item 3):
 
  [3] Note that since there are no guarantees on the state of the
  properties, a tag handler that had some optional properties set can
  only be reused if those properties are set to a new (known)
  value. This means that tag handlers can only be reused within the same
  "AttSet" (set of attributes that have been set).

This means that while the same tag handler instance may be used to
service these tags:

  
  
  
  

it may not be used to service

  

One of the ideas we have considered is to support tag reuse on a
per-page basis, without allowing tag handlers to be shared across
simultaneous page invocations. In this approach, each custom tag is
assigned a tag handler variable name at compile time, based on its
full name, its attribute names, and its nesting level (with respect to
tags with the same name and AttSet). According to this, the two
 tags in:

  

  

  

would be assigned the same tag handler variable name (both are at
nesting level 0 with respect to their tag "class"), whereas the two
 tags in:

  

  

  

would be assigned different tag handler variable names, because they
are at different nesting levels. All tag handler variables determined
in this fashion would be declared as (local) variables at the beginning of
the _jspService() method.

The advantages of this approach would be:
- No need for synchronization.
- Tag handler reuse is determined at compile time.

Disadvantages would be:
- Tag handlers are not shared across multiple page invocations.
- Does not work well with the proposed approach to remove the 64K limit,
since a (possibly large) number of tag handlers would have to be
passed as arguments to (sub)method calls.

--
PROPOSAL:

An alternative proposal that we discussed would allow for tag pooling
across page invocations, using a stack-based approach.

With this approch, each node representing a custom tag is assigned as one
of its fields (at compile time) the name of a tag handler stack,
based on the tag's full name and attribute set (tag's nesting level is
ignored).
All tag handlers in the same stack are intended to be shared among tags
with the same name and attribute set.

For example, if this tag is encountered:

  

a tag handler for it is acquired from the stack named a_b_c_d. If
this stack is empty, a new tag handler is created. When the tag
handler is no longer in use, it is pushed back on the stack so it
can be reused.

The tag handler stacks are declared as instance variables (and
therefore won't need to be passed as arguments to any (sub)method
calls implemented as part of the proposal to remove the 64K limit).

Notice that this approach is very similar to what was done in Tomcat
3.x, except that we would get rid of the TagPoolManager, which stored
all the tag handler stacks (pools) in a hashtable (keyed by the pool
name). This would save us a hash operation and synchronization (on the
hashtable) on every stack lookup.

Note that this approach allows for optimizations in
iterations. Instead of acquiring a tag handler from the appropriate
stack and returning it to the stack in each iteration step, the tag
handler could be acquired at the beginning of the iteration and held
on to for the duration of the iteration.

If this sounds like a reasonable approach, I'll go ahead and provide a
patch for Jasper 2 implementing it.


Jan





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