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.