[ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136238#comment-15136238 ]
David Geleyn edited comment on FOP-2525 at 2/8/16 11:22 AM: ------------------------------------------------------------ First of all, I have no expert knowledge of the FOP code base. I did some profiling with VisualVM and I think I found the cause, but it needs verification. I found that the org.apache.fop.complexscripts.fonts.GlyphTable class doesn't have an explicit hashCode and equals method. I added those functions and did not take into account the matchedLookups member in those functions as it seemed to be a kind of cache. So I assumed that 2 instances of a GlyphTable could be equal, even if they have a different cached set in the matchedLookups member. That seems to do the trick. No OOM anymore and the PDF's look good. This is the code I added in the org.apache.fop.complexscripts.fonts.GlyphTable class @Override public int hashCode() { int hc = 0; hc = 7 * hc + (hc ^ lookups.hashCode()); hc = 11 * hc + (hc ^ lookupTables.hashCode()); hc = 23 * hc + (hc ^ (frozen ? 107 : 89)); if (gdef != null) { hc = 5 * hc + (hc ^ gdef.hashCode()); } return hc; } @Override public boolean equals(Object obj) { if (obj instanceof GlyphTable) { final GlyphTable table = (GlyphTable)obj; if (!this.lookups.equals(table.lookups)) return false; if (!this.lookupTables.equals(table.lookupTables)) return false; if (this.gdef != null && table.gdef == null) return false; if (this.gdef == null && table.gdef != null) return false; if (this.gdef != null && table.gdef != null) { if (!this.gdef.equals(table.gdef)) return false; } return this.frozen == table.frozen; } return false; } was (Author: david.gel...@gmail.com): First of all, I have no expert knowledge of the FOP code base. I did some profiling with VisualVM and I think I found the cause, but it needs verification. I found that the org.apache.fop.complexscripts.fonts.GlyphTable class doesn't have an explicit hashCode and equals method. I added those functions and did not take into account the matchedLookups member in those functions as it seemed to a kind of cache. So I assumed that 2 instances of a GlyphTable could be equals, even if they had a different cached set in the matchedLookups member. That seems to do the trick. No OOM anymore and the PDF's look good. This is the code I added in the org.apache.fop.complexscripts.fonts.GlyphTable class @Override public int hashCode() { int hc = 0; hc = 7 * hc + (hc ^ lookups.hashCode()); hc = 11 * hc + (hc ^ lookupTables.hashCode()); hc = 23 * hc + (hc ^ (frozen ? 107 : 89)); if (gdef != null) { hc = 5 * hc + (hc ^ gdef.hashCode()); } return hc; } @Override public boolean equals(Object obj) { if (obj instanceof GlyphTable) { final GlyphTable table = (GlyphTable)obj; if (!this.lookups.equals(table.lookups)) return false; if (!this.lookupTables.equals(table.lookupTables)) return false; if (this.gdef != null && table.gdef == null) return false; if (this.gdef == null && table.gdef != null) return false; if (this.gdef != null && table.gdef != null) { if (!this.gdef.equals(table.gdef)) return false; } return this.frozen == table.frozen; } return false; } > Memory leak present when using Truetype Collection (.ttc) > --------------------------------------------------------- > > Key: FOP-2525 > URL: https://issues.apache.org/jira/browse/FOP-2525 > Project: FOP > Issue Type: Bug > Affects Versions: 2.0 > Environment: At least Mac and Linux, both Oracle VM and OpenJDK > Reporter: Jeremy Smith > Priority: Minor > > When a TrueType Collection file is used to specify custom fonts, and a > long-running FopFactory is used to create FOP instances to process many FO > input documents, millions of > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and > org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances > get created which are never collected. Thus the heap continues to grow, > leading to eventual GC thrashing or crash. > When the same fonts are used, but extracted from the TTC file, the issue does > not occur, and the instances of those classes are collected normally. > The issue can be seen by repeatedly processing a document with a config.xml > which specifies fonts inside of a Truetype Collection file. Attaching > VisualVM to such a process will show continuous heap growth and millions of > aforementioned instances whose numbers never decrease. -- This message was sent by Atlassian JIRA (v6.3.4#6332)