On Jul 3, 2006, at 15:19, karthik wrote:
Hi,
Like you said, I agree that once memory is allocated JVM does not
release it.
But, why would the process slow down gradually and eventually die?
Isn't this a
indication of a memory leak?
Not necessarily. It just means that, given FOP's architecture,
instances of FObj subclasses will be created for each FO node in your
document. Those instances will, under normal circumstances, be
released at the end-of-layout for every page-sequence node. If your
document is not split up into multiple page-sequences, then this
means the same as end-of-layout for the whole document.
For every node in the page-sequence (more or less) a LayoutManager
instance is created, and these ultimately build a tree of Area
objects. If your document contains forward-references (page-number-
citations to the end of the document), currently all those Areas will
be released only after those references are fully resolved.
The more the heap starts filling, the less remaining space you have
to work with, until the maximum is reached. By that time, the main
thread will most likely be running extremely slow.
If the GC is moderately intelligent, it will be able to check
relatively quickly if there are *any* objects that are no longer
referenced, giving the impression of not running at all (dying out;
immediately returning control to the main-thread). If no objects can
be released, then GC can do no more than wait for the main thread to
continue, and check back later --and since the main thread runs so
slowly, much, much later...
Pl. let eme know if you have any suggestions or
comments to improve the performance of this process.
See above: memory leak? Not if a 'leak' means 'keeping *unnecessary*
references alive'. A lot depends on the structure of your FO document...
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
