Hi!
I am facing a strange memory problem with FOP 0.95. I have a rather
large xsl-fo file (size 10 574 859 bytes) containing references to 1062
svg images and resulting in a 683 page pdf. What is strange is that FOP
renders this fine on a 32-bit jvm, but fails with "GC overhead limit
exceeded" on a 64-bit jvm even if given double the memory the 32-bit
process is given.
Here's the exception:
14.6.2010 11:33:10 org.apache.fop.render.AbstractRenderer renderXML
SEVERE: Some XML content will be ignored. Could not render XML
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.Arrays.copyOfRange(Unknown Source)
at java.lang.String.<init>(Unknown Source)
at java.lang.StringBuffer.toString(Unknown Source)
at org.apache.batik.bridge.SVGFontUtilities.getFontFamily(Unknown
Source)
at
org.apache.batik.bridge.SVGTextElementBridge.getFontList(Unknown Source)
at
org.apache.batik.bridge.SVGTextElementBridge.getAttributeMap(Unknown
Source)
at
org.apache.batik.bridge.SVGTextElementBridge.fillAttributedStringBuffer(Unknown
Source)
at
org.apache.batik.bridge.SVGTextElementBridge.buildAttributedString(Unknown
Source)
at
org.apache.batik.bridge.SVGTextElementBridge.computeLaidoutText(Unknown
Source)
at
org.apache.batik.bridge.SVGTextElementBridge.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown
Source)
at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
at
org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188)
at
org.apache.fop.render.AbstractGenericSVGHandler.handleXML(AbstractGenericSVGHandler.java:57)
at
org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:808)
at
org.apache.fop.render.PrintRenderer.renderDocument(PrintRenderer.java:169)
at
org.apache.fop.render.pdf.PDFImageHandlerXML.generateImage(PDFImageHandlerXML.java:55)
at
org.apache.fop.render.pdf.PDFRenderer.putImage(PDFRenderer.java:1745)
at
org.apache.fop.render.pdf.PDFRenderer.renderImage(PDFRenderer.java:1679)
at
org.apache.fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:743)
at
org.apache.fop.render.AbstractPathOrientedRenderer.renderViewport(AbstractPathOrientedRenderer.java:621)
at
org.apache.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:626)
at
org.apache.fop.render.pdf.PDFRenderer.renderInlineArea(PDFRenderer.java:1345)
at
org.apache.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:601)
at
org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:1336)
FOP does not stop at the first one - there are several of these in FOP
output. The resulting pdf is broken, though.
Here's version information on the 32-bit jvm (that is able to perform
the task both with -client and -server jvms):
C:\Temp>java -version
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
And here's the corresponding info for the 64-bit jvm (only -server jvm
available):
g:\work>java -version
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)
On 32-bit jvm -Xmx500m is sufficient, but on the 64-bit jvm even
-Xmx1000m is not enough.
Any ideas on how to get around this are much appreciated.
::Antti::
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
