This is by design.
Saxon uses a NamePool object to hold names used in source documents and
stylesheets. Each name is allocated a unique integer code, which is used
when matching names. It's vital that in any transformation, the source
document and stylesheet use the same NamePool.
In general, you can transform one source document using many stylesheets, or
many source documents using the same stylesheet, or any combination. This
means that Saxon can't simply allocate a new NamePool for each source
document, or for each stylesheet. By default, for a single run of Saxon,
everything you do will go in the same NamePool. This will gradually increase
in size if the vocabulary used in the source documents and stylesheets is
If you want more precise control, you can allocate your own NamePool objects
manually. If you do this, however, Saxon performs a check that for a given
transformation, the same NamePool was used when building the source document
and when building the stylesheet. It does this by keeping in the NamePool a
list of hashcodes of the stylesheets that have been compiled using that
NamePool. This is the 50 bytes that you are noticing is being added each
(The code is actually being very careful to hold only a hashcode, and not a
reference to the stylesheet, which means that the garbage collecter is free
to release the stylesheet when no longer needed. Given that Saxon is now
dependent on JDK 1.2, I could actually switch to using a WeakHashMap for
If this is the only growth you are seeing, it suggests to me that you are
compiling stylesheets repeatedly, but the vocabulary in use is stable.
Perhaps you should be saving the compiled stylesheet and re-using it? If you
are making minor modifications to the stylesheet each time its used, are
these actually necessary, or could the effect be achieved by massing
parameters, or calling saxon:evaluate()?
If gradual growth in the size of the NamePool becomes a problem, then you
will need to manage NamePools manually instead of relying on the default
system-allocated NamePool. If neither source documents nor stylesheets are
being reused, the simplest such scheme is to allocate a new NamePool for
For completeness I will add a method that allows a hashcode signature to be
removed from the namepool if the client knows that a given stylesheet will
not be used again.
(To be pedantic, the term "memory leak" is never correct when referring to
100% Java code. It's not that memory is being lost, it's that memory is
being used to hold information that isn't actually needed any more. It
amounts to the same thing as far as users are concerned, but is a very
different problem technically).
> -----Original Message-----
> From: saxon-help-admin@...
> [mailto:saxon-help-admin@... Behalf Of Sonali J.
> Sent: 09 January 2002 15:19
> To: SAXON XSL Discussion List
> Subject: [saxon] Memory leak in Saxon 6.4.2
> While using Saxon 6.4.2 with Xerces 1.4.1, during every call to
> TemplatesHandler.getTemplates( ) I'm noticing an
> approximately 50 bytes
> memory leak.
> When analyzing with a memory analyzer tool, I see a number of
> objects being created at :
> NamePool.setStylesheetSignature( ) in NamePool.java: line 144.
> Is this a known issue? If yes, then has it been fixed in
> newer versions
> Any information would be appreciated.
> saxon-help mailing list