Chris:
> Yeah, it's possible (and probable) that the TagHandlerPool
> maintains a
> reference back to the ServletContext in which it lives. That
> might kew
> your results. I'm sure that the TagHandlerPool isn't actually
> taking up
> that much memory.
This is strange. When I created a heap dump from my server
just now, it does not have any instances of TagHandlerPool
in the heap dump. That is what I expected before, but I still
had them in my last dump.
> Do you have any of your own tag libraries, or are you using only
> 3rd-party taglibs? If you are using your own, check to see if you are
> holding on to references or something like (anything like
> shared objects
> between tags -- that kind of thing).
We are not using any 3rd party tag libraries.
We are using our our tag library. I will look into that.
> If you have a profiler handy (something more robust that the heap
> dumper), check to see how many instances of various types
> there are. For
> example, if you are using org.foo.bar.taglib, then filter the object
> list by org.foo.bar.taglib and take a look at how many
> instances there
> are. If you find that there are thousands of references to
> tag handlers,
> then something is probably wrong with Tomcat. Otherwise,
> several hundred
> references doesn't sound horrible. It's possible that they
> haven't been
> GC'd yet.
Doing a quick grep on my summary results from the new heap dump,
I get this result:
60256,1076,com/slsideas/pagegen/tags/SetPropertyTag
31296,652,com/slsideas/pagegen/tags/ValueTag
23088,481,com/slsideas/pagegen/tags/ProcessTag
13008,271,com/slsideas/pagegen/tags/IfNotNullTag
9888,206,com/slsideas/pagegen/tags/IfNullTag
9600,200,com/slsideas/pagegen/tags/IfEqTag
5616,117,com/slsideas/pagegen/tags/IfExistTag
4992,104,com/slsideas/pagegen/tags/IfNotEqTag
3216,67,com/slsideas/pagegen/tags/IncludeTag
3136,49,com/slsideas/pagegen/tags/LoopTag
960,20,com/slsideas/pagegen/tags/IfNotExistTag
608,2,class com/slsideas/pagegen/tags/ValueTag
608,2,class com/slsideas/pagegen/tags/SetPropertyTag$Converter
608,2,class com/slsideas/pagegen/tags/SetPropertyTag
608,2,class com/slsideas/pagegen/tags/ProcessTag
608,2,class com/slsideas/pagegen/tags/IncludeTag
608,2,class com/slsideas/pagegen/tags/IfNotExistTag
608,2,class com/slsideas/pagegen/tags/IfExistTag
608,2,class com/slsideas/pagegen/tags/BaseTag
304,1,class com/slsideas/pagegen/tags/LoopTag
304,1,class com/slsideas/pagegen/tags/IfNullTag
304,1,class com/slsideas/pagegen/tags/IfNotNullTag
304,1,class com/slsideas/pagegen/tags/IfNotEqTag
304,1,class com/slsideas/pagegen/tags/IfLoopTag
304,1,class com/slsideas/pagegen/tags/IfGreaterThanTag
304,1,class com/slsideas/pagegen/tags/IfGreaterOrEqTag
304,1,class com/slsideas/pagegen/tags/IfEqTag
304,1,class com/slsideas/pagegen/tags/EscapeValueTag
56,1,com/slsideas/pagegen/tags/IfLoopTag
The first column is the total bytes held by the instance inself (not
including
references), the second column is the number of instances that were
present
in the heap dump, and the last column is the type of the object.
I find it very hard to believe that we have over 2500 active instances
of
our tags. This seems to imply they are not being garbage collected.
> I also noticed that you are using JDK 1.4.1. I've heard that this
> version (it might only be the Sun distro -- can someone
> confirm?) has an
> implementation of StringBuffer that has a terrible memory leak. You
> might want to consider upgrading to 1.4.2 if that's possible.
I ran some code to count all of the instances of java/lang/StringBuffer
and the total bytes they hold both in themselves and their references.
I got 2,925,512 bytes in 15,914 instances of java/lang/StringBuffer.
The heap dump shows 174,740,832 total bytes used in 892,512 total
instances.
I don't belive the StringBuffer is the cause of my problems.
Thanks,
Neil.
--
Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com
FREE! Valuable info on how your business can reduce operating costs by
17% or more in 6 months or less! => http://newsletter.JAMMConsulting.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
