Jasper34: static output changes

[cm...@yahoo.com]

Ok, time to discuss the first mini-optimization.

Right now jasper has 2 ways to output data - one is the common 
out.println("String ");

The other ( not very used ) is using an additional file to store the 
strings, and it's enabled by "largefile" option.

The output system is probably the most important part of jasper ( except
taglibs ) with regard to performance. 

My proposal is to drop the first option, which is also failing for chunks
bigger than 64k ( due to .class file limitations on constant pool
strings), and use the second ( with some changes ) in all cases.

The main problem is that the java file will be less readable ( 
out.println( strings[4] ) instead of the real string ). That can be
resolved easily by generating a comment with the real string ( most users
will not read the java file - now that we are close to line number
mapping it'll happen even less ).

Note that this is nothing new for jasper - the option has been present in
jasper and is tested. 

The main benefits:

- full control over static content allocation. If the strings are part of
the constant pool, they are loaded with the class and garbage collected
only if the class itself is gc. By loading them from the file we could
easily add a LRU cache for the static chunks and reduce the runtime memory
usage quite significantly.

- ability for containers to control the static content. For a large file
the connector could send only the file and offsets to apache, instead of
reading and sending the large chunk.

- it will work with large files without requiring users to set options
( that could be resolved by detecting large chunks and turning it on
automatically )

- a single output model - easier to test and optimize than 2.

Let me know if you see any problem with that - it'll probably happen next
week, I'm still stuck with the JspServlet. 

Costin
 

Re: Jasper34: static output changes

[cm...@yahoo.com]

On Sat, 16 Jun 2001, Casey Lucas wrote:

> > Jasper already understands what things like <jsp:useBean> do, and it
> > generates specialized code to implement the required functionality (rather
> > than treating it like a custom tag).
> 
> right.  i thought he might be refering to custom tags.  that's where my
> concern was.  for the standard stuff, i'm sure we can inline / optimize
> plenty.

I'm refering to inlining some common custom tags, with an eye toward more
complex optimizations. My bet is that rewriting the output system plus
inlining for/if and few other tags would get us the most gains. 

Costin

Re: Jasper34: static output changes

[Casey Lucas <cl...@armassolutions.com>]

"Craig R. McClanahan" wrote:
> 
> On Sat, 16 Jun 2001, Casey Lucas wrote:
> 
> >
> > cmanolache@yahoo.com wrote:
> > >
> > > On Fri, 15 Jun 2001, Casey Lucas wrote:
> > >
> > > >
> > > > Costin,
> > > >
> > > > sounds good.
> > > >
> > > > btw, when do you think the generator code in 34 will settle down
> > > > a little?
> > >
> > > Soon :-)
> > >
> > > There is only one more change in the generator layout - switching to
> > > a "visitor" pattern, with the tree representation of the page separated
> > > from the actual generator.
> > >
> > > If you are thinking to tagpool changes - please wait until RuntimeLiaison
> > > gets a bit of shape, I would like to provide some hooks for the container
> > > to control the pools. Again, the idea is to allow a "toolkit" model, where
> > > different components can be plugged in.
> >
> > ok.  just let me know when you think it's appropriate to
> > start adding some tag optimizations.
> >
> > > Separating tree is very important to allow modules to do various
> > > optimizations ( like replacing common tags with equivalent in-line java
> > > code ) and to do the direct bytecode generation.
> >
> > regarding "replacing common tags with equivalent in-line java code":  what
> > exactly did you have in mind?
> >
> 
> Jasper already understands what things like <jsp:useBean> do, and it
> generates specialized code to implement the required functionality (rather
> than treating it like a custom tag).

right.  i thought he might be refering to custom tags.  that's where my
concern was.  for the standard stuff, i'm sure we can inline / optimize
plenty.

> 
> With the advent of the JSP Standard Tag Library (being designed by the
> expert group on JSR 52), there will be a much larger number of tags that
> are suitable for this type of analysis -- things like conditional and
> iteration tags, where you can generate much more efficient native Java
> code instead of all the overhead of calling a regular custom tag.
> 
> > -casey
> >
> 
> Craig

Re: Jasper34: static output changes

["Craig R. McClanahan" <cr...@apache.org>]

On Sat, 16 Jun 2001, Casey Lucas wrote:

> 
> cmanolache@yahoo.com wrote:
> > 
> > On Fri, 15 Jun 2001, Casey Lucas wrote:
> > 
> > >
> > > Costin,
> > >
> > > sounds good.
> > >
> > > btw, when do you think the generator code in 34 will settle down
> > > a little?
> > 
> > Soon :-)
> > 
> > There is only one more change in the generator layout - switching to
> > a "visitor" pattern, with the tree representation of the page separated
> > from the actual generator.
> > 
> > If you are thinking to tagpool changes - please wait until RuntimeLiaison
> > gets a bit of shape, I would like to provide some hooks for the container
> > to control the pools. Again, the idea is to allow a "toolkit" model, where
> > different components can be plugged in.
> 
> ok.  just let me know when you think it's appropriate to
> start adding some tag optimizations.
> 
> > Separating tree is very important to allow modules to do various
> > optimizations ( like replacing common tags with equivalent in-line java
> > code ) and to do the direct bytecode generation.
> 
> regarding "replacing common tags with equivalent in-line java code":  what
> exactly did you have in mind?
> 

Jasper already understands what things like <jsp:useBean> do, and it
generates specialized code to implement the required functionality (rather
than treating it like a custom tag).

With the advent of the JSP Standard Tag Library (being designed by the
expert group on JSR 52), there will be a much larger number of tags that
are suitable for this type of analysis -- things like conditional and
iteration tags, where you can generate much more efficient native Java
code instead of all the overhead of calling a regular custom tag.

> -casey
> 

Craig

Re: Jasper34: static output changes

[cm...@yahoo.com]

On Sat, 16 Jun 2001, Casey Lucas wrote:

> ok.  just let me know when you think it's appropriate to
> start adding some tag optimizations.

I assume the changes will be local to 2-3 generators and runtime. We
should be able to have them in parallel, it would generate some conflicts
in cvs but we can easily merge them. On the other side, it would help me a
lot to have more pairs of eyes to validate the refactored architecture 
as it moves forward. 

> > Separating tree is very important to allow modules to do various
> > optimizations ( like replacing common tags with equivalent in-line java
> > code ) and to do the direct bytecode generation.
> 
> regarding "replacing common tags with equivalent in-line java code":  what
> exactly did you have in mind?

Some tags are likely to be used very frequently ( for, if, etc). A simple
thing we can do is to take the JspTree ( after separating the page
representation from the generators with visitor-like pattern ) and do a
number of optimizations before generating the code. 

This is one of the simplest - walk the tree and look for some tags, and 
replace them with equivalent in-line java code. That would save quite a
bit of overhead - creating and pooling the tag, manipulating the variables
via hashtables, multiple method invocations. 

There are many other optimizations that we can do on the tree ( including
elimination of duplicated initializers, etc) - that's how most compilers
work. 



If you remember the discussion about XSLT, that's one of the places I
thing it might make a big difference. The code to do more advanced
processings on the tree can get extremely complex - and will end up
duplicating a lot from xslt ( we'll just do tree manipulations - searching
for patterns in a tree and generating tree fragments ). XSLT has all the
power it needs to do that and provide a standard behavior, as oposed to an
internal API we can define ( assuming we duplicate most of the code from
xslt ).

For simple things like replacing tags with equivalent java scriptlets we
don't need to wait for XSLT, but long term the code can become very hard 
to understand as it starts doing advanced things ( by duplicating the
xpath and templates ).


BTW, that does _not_ matter for a developer - optimizations could be
easily turned off so it'll not affect the compile time for development
mode. It will matter when you deploy on a production server where few
modifications happen ( or off-line precompilation is used ) - and the
extra time it takes to optimizat the code is not important. 


Costin   

Re: Jasper34: static output changes

[Casey Lucas <cl...@armassolutions.com>]

cmanolache@yahoo.com wrote:
> 
> On Fri, 15 Jun 2001, Casey Lucas wrote:
> 
> >
> > Costin,
> >
> > sounds good.
> >
> > btw, when do you think the generator code in 34 will settle down
> > a little?
> 
> Soon :-)
> 
> There is only one more change in the generator layout - switching to
> a "visitor" pattern, with the tree representation of the page separated
> from the actual generator.
> 
> If you are thinking to tagpool changes - please wait until RuntimeLiaison
> gets a bit of shape, I would like to provide some hooks for the container
> to control the pools. Again, the idea is to allow a "toolkit" model, where
> different components can be plugged in.

ok.  just let me know when you think it's appropriate to
start adding some tag optimizations.

> Separating tree is very important to allow modules to do various
> optimizations ( like replacing common tags with equivalent in-line java
> code ) and to do the direct bytecode generation.

regarding "replacing common tags with equivalent in-line java code":  what
exactly did you have in mind?

-casey

Re: Jasper34: static output changes

[cm...@yahoo.com]

On Fri, 15 Jun 2001, Casey Lucas wrote:

> 
> Costin,
> 
> sounds good.
> 
> btw, when do you think the generator code in 34 will settle down
> a little?

Soon :-)

There is only one more change in the generator layout - switching to
a "visitor" pattern, with the tree representation of the page separated
from the actual generator. 

If you are thinking to tagpool changes - please wait until RuntimeLiaison
gets a bit of shape, I would like to provide some hooks for the container
to control the pools. Again, the idea is to allow a "toolkit" model, where 
different components can be plugged in.

Separating tree is very important to allow modules to do various
optimizations ( like replacing common tags with equivalent in-line java
code ) and to do the direct bytecode generation.

Costin

Re: Jasper34: static output changes

[Casey Lucas <cl...@armassolutions.com>]

Costin,

sounds good.

btw, when do you think the generator code in 34 will settle down
a little?

-casey

cmanolache@yahoo.com wrote:
> 
> Ok, time to discuss the first mini-optimization.
> 
> Right now jasper has 2 ways to output data - one is the common
> out.println("String ");
> 
> The other ( not very used ) is using an additional file to store the
> strings, and it's enabled by "largefile" option.
> 
> The output system is probably the most important part of jasper ( except
> taglibs ) with regard to performance.
> 
> My proposal is to drop the first option, which is also failing for chunks
> bigger than 64k ( due to .class file limitations on constant pool
> strings), and use the second ( with some changes ) in all cases.
> 
> The main problem is that the java file will be less readable (
> out.println( strings[4] ) instead of the real string ). That can be
> resolved easily by generating a comment with the real string ( most users
> will not read the java file - now that we are close to line number
> mapping it'll happen even less ).
> 
> Note that this is nothing new for jasper - the option has been present in
> jasper and is tested.
> 
> The main benefits:
> 
> - full control over static content allocation. If the strings are part of
> the constant pool, they are loaded with the class and garbage collected
> only if the class itself is gc. By loading them from the file we could
> easily add a LRU cache for the static chunks and reduce the runtime memory
> usage quite significantly.
> 
> - ability for containers to control the static content. For a large file
> the connector could send only the file and offsets to apache, instead of
> reading and sending the large chunk.
> 
> - it will work with large files without requiring users to set options
> ( that could be resolved by detecting large chunks and turning it on
> automatically )
> 
> - a single output model - easier to test and optimize than 2.
> 
> Let me know if you see any problem with that - it'll probably happen next
> week, I'm still stuck with the JspServlet.
> 
> Costin
>

Re: Jasper34: static output changes

[Glenn Nielsen <gl...@voyager.apg.more.net>]

+1

cmanolache@yahoo.com wrote:
> 
> Ok, time to discuss the first mini-optimization.
> 
> Right now jasper has 2 ways to output data - one is the common
> out.println("String ");
> 
> The other ( not very used ) is using an additional file to store the
> strings, and it's enabled by "largefile" option.
> 
> The output system is probably the most important part of jasper ( except
> taglibs ) with regard to performance.
> 
> My proposal is to drop the first option, which is also failing for chunks
> bigger than 64k ( due to .class file limitations on constant pool
> strings), and use the second ( with some changes ) in all cases.
> 
> The main problem is that the java file will be less readable (
> out.println( strings[4] ) instead of the real string ). That can be
> resolved easily by generating a comment with the real string ( most users
> will not read the java file - now that we are close to line number
> mapping it'll happen even less ).
> 
> Note that this is nothing new for jasper - the option has been present in
> jasper and is tested.
> 
> The main benefits:
> 
> - full control over static content allocation. If the strings are part of
> the constant pool, they are loaded with the class and garbage collected
> only if the class itself is gc. By loading them from the file we could
> easily add a LRU cache for the static chunks and reduce the runtime memory
> usage quite significantly.
> 
> - ability for containers to control the static content. For a large file
> the connector could send only the file and offsets to apache, instead of
> reading and sending the large chunk.
> 
> - it will work with large files without requiring users to set options
> ( that could be resolved by detecting large chunks and turning it on
> automatically )
> 
> - a single output model - easier to test and optimize than 2.
> 
> Let me know if you see any problem with that - it'll probably happen next
> week, I'm still stuck with the JspServlet.
> 
> Costin
> 

-- 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------