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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
