DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44358>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44358





------- Additional Comments From [EMAIL PROTECTED]  2008-02-13 11:11 -------
(In reply to comment #7)
> 
> We modified FOP 0.94 as Vincent suggested (thanks!). This resolved the 
> infinite 
> loop problem.  However we still get the OutOfMemory exception.  

OK, thanks a lot for trying this out. Can you judge whether the exception 
occurred sooner or later than 
with FOP 0.93?

> I am wondering if the FOP framework holds large amount of memory in static 
> class variables.

Not that I'm aware of. There are some static variables in the property classes, 
but those only serve to 
reduce the footprint. (caches that are shared between different FOs in the same 
document, or even in 
different documents if they are processed concurrently in the same JVM)

> Also I noticed that there are a very large number of 
> fop.fo.StaticPropertyList 
> objects created - 35000

That means your FO contains 35000 objects, which is not abnormal for larger 
documents. If those are 
all inside the same page-sequence, there is only little you can do for the 
moment, apart from making 
sure that such an FO document is never generated in the first place. This could 
be done by 
restructuring the stylesheet to generate multiple page-sequences, but we 
realize that this is not always 
possible.

In the old days, those PropertyLists were never released. Being attached to the 
corresponding FONode 
(hard member reference), they were only released when that FONode was no longer 
referenced.
Currently, they are more like a window, from which the relevant properties are 
transferred to the 
FONode during parsing. As soon as the endElement() event occurs for that 
FONode, the PropertyList 
goes out of scope and should theoretically be 100% garbage-collectable 
(including the backing arrays)

> ; each of those objects holds two arrays - size 252.  

Yep. 252 is the total number of possible properties.

> This correlates with the heapdump analyses we performed - large number of 
> arrays without parent and the GC cannot dispose them. (I am under the 
> impression that these objects get allocated in a recursive manner.)

Correct, although the number of StaticPropertyLists to which there exists a 
hard reference will be 
determined not by the number of FOs, but by the nesting level. If you have a 
document with a 
maximum nesting depth of 10 nodes, then there will be at most 10 
StaticPropertyList instances alive at 
any given point during the processing. I've literally seen this with my own 
eyes during a profiling 
session.

Is it normal that the backing arrays are not collected? I'd think not, but I'm 
not 100% sure.

Which JVM is used? Are you using Sun's implementation, or an IBM JVM? Is there 
a way to rule out the 
possibility of the GC algorithm being at fault here? Can you try other Java 
Runtimes?

> Would it be possible to reduce the number of arrays using static var or 
> object 
> cache?

Not really, I think... The properties themselves are already cached for a large 
part, i.e. a simple 
FixedLength with a value of "10pt" will be the same instance for all 
occurrences in the document.
Initially, each FixedLength is a separate instance, but we check immediately 
whether we already have 
one cached with the same value. If that is the case, then the separate instance 
exists purely on the 
stack, and is substituted with the cached instance before it is attached/bound 
to the FONode.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to