On Fri, 2003-11-21 at 15:50, J.Pietschmann wrote:
> John Austin wrote:
> > It is clear that there is a fair bit of memory freed by Driver.reset(). 
> > 
> > After thinking it over, I modified the same test to skip reset() and
> > just null the reference and issue System.gc().
> > 
> > This should be the same as letting it go out of scope (which happens
> > afterwards but this way I get the square wave on the graph).
> > 
> > Attachment 2: footprint2.png has about 1Mb more heap in use!
> Shrug. The Driver.reset() is
>          _source = null;
>          _stream = null;
>          _reader = null;
>          _treeBuilder.reset();
> and the tree builder's reset in turn is
>          currentFObj = null;
>          rootFObj = null;
>          streamRenderer = null;
>         this.errorCount = 0;

Why bother implementing reset() ?

> There are no static variables explicitely freed (there are not much
> static variables in FOP in general). I don't see any difference calling
> reset() can make compared to simply nulling the Driver reference.
> > Why ? Does this suggest that there are finalizers (destructors) that are
> > not being called ? References set to null inside reset() should all
> > be unreachable when the reference to Driver goes out of scope.
> You realize that gc() doesn't *force* a GC?
> The most reliable way to measure  allocated heap space I know off is
> allocating a large byte[][] array, then allocate 1k byte[] or so
> until you run out of memory.

Yes. But the observations were convincing. It is obvious that much
garbage was collected as expected. It was possible that the garbage
collector did not collect ALL of the garbage at that point but I
didn't understand how that could happen. I thought that the GC 
would examine every object to determine it's status. This seemed to
imply that you MUST collect all garbage every time.

I overlooked the possibility of multiple storage pools.

> > This might explain problems people are reporting when 
> > generating multiple PDF files using FOP. Especially if their
> > programs don't lose references to instances of Driver.
> Well, if they hang on to the Driver object, they are doomed.
> > Personally, I suspect there are a lot of logical memory leaks
> > inside FOP.
> What's a logical memory leak?

The only kind you can get in Java. Referenced memory that is never
used again. 

In the case of FOP, this includes objects which have been laid out
in the PDF never to be used again. FOP memory use increases >= O(n)
where n is the number of pages being created. This is easy to show.

Massive amounts of memory are released when Driver is reset() or

I still object to the extreme high water marks in FOP. The saw-tooth
pattern is described in the JMP documentation as characteristic of
the creation of too many objects. This is probably fundamental to 
XSL-FO but the high-water mark of memory use would be lower if objects
were collected sooner. This would also speed up collection as there
would be fewer objects to inspect.


Reply via email to