Hi Antti, Let's blame java:
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.oom Regards, Georg Datterl ------ Kontakt ------ Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de -----Ursprüngliche Nachricht----- Von: Antti Karanta [mailto:[email protected]] Gesendet: Montag, 14. Juni 2010 11:50 An: [email protected] Betreff: GC overhead limit exceeded on a 64-bit jvm 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
