tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <>
Subject Re: Jsp pages with scriptlet and javadoc comments loaded in char[]
Date Wed, 02 May 2018 17:31:01 GMT
On 5/2/2018 07:30, M. Manna wrote:
> 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
> remove
> 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
> option.
> Thanks,

Pre-compiling the JSP pages might be worth consideration.

-Terence Bandoian

> 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