tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. Manna" <>
Subject Re: Jsp pages with scriptlet and javadoc comments loaded in char[]
Date Wed, 02 May 2018 12:30:33 GMT
Hi Mark,

Basically, our application has quite a lot of large objects which are
singletons. When we checked the list of char[] objects loaded in the
memory, some of them showed JspServlet related Strings and had commented
code loaded into char[].
we have quite a lot of Strings loaded in memory (using maps) which are
necessary. heap-dump will always report this as a memleak but it's not - So
trying to understand whether we can utilise anything from tomcat side to
I understand it sounds odd, but at that point it appeared to be something
we can just strip out. But from your comments, it doesn't seem to be an


On 2 May 2018 at 10:39, Mark Thomas <> wrote:

> On 02/05/18 10:31, M. Manna wrote:
> > Hi All,
> >
> > I had a specific question regarding JSPs loaded in web-application
> > container for jasper to compilation. If I have a JSP page which has
> > scriptlet and javadoc comments/code comments, aren't those loaded into
> the
> > char[] of JSP pages too?
> No.
> > I understand that Jasper compiles the JSPs but
> > those comments aren't stripped out (apologies if I have missed something
> in
> > source code). I am using tomcat 8.5.28.
> Yes, they are. HTML comments (which are essentially template text) are not.
> > In other words, by cutting down all javadoc comments/commented code from
> > JSP scriptlets, can I assume some savings will be made in terms of char[]
> > memory size when my servers are very busy? I have about ~3k JSP pages
> with
> > a mixture of nice clean JSPs and really messy scriptlets. And I am trying
> > to find some options to tune GC and see if reducing char[] sizes can help
> > me in any way.
> Seems like an odd way to tune GC. What problem are you trying to solve?
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message