You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "David Geleyn (JIRA)" <ji...@apache.org> on 2016/02/08 12:22:39 UTC
[jira] [Comment Edited] (FOP-2525) Memory leak present when using
Truetype Collection (.ttc)
[ 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.geleyn@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)