Re: Memory measurement -- importance of Driver.reset()

[J.Pietschmann]

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;
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.
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?

J.Pietschmann