Ben Galbraith wrote:
If you haven't figured it out yet, let me inform you: FOP suffers from
large memory leaks.
Where? Class names?
FOP often uses a huge amount of memory during rendering, but once the
driver object is released, most of it is eglible for GC. Memory locked
accross rendering runs must be referenced by static variables, and a
careful inspection of the code shows there aren't many such things.
Most notably:
- Image cache. No issue if it is reset.
- A few string buffers used as, well, buffers in various places. They
should grow of the order of text strings in the input, at most of
the order of total text content in the largest block. Complete analysis
is still pending.
- Configuration data.
This does not rule out there are hidden leaks elsewhere, perhaps
introduced through the Java run time library. If anybody experiencing
rapid growth of locked down memory after several runs of FOP could
do experiments which kind of FO constructs is likely responsible for
this, or preferably run a memory profiler, this would be of great help
in tracking down the problem. My experiments so far failed to get a hold
on this.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
