[ 
https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136238#comment-15136238
 ] 

David Geleyn commented on FOP-2525:
-----------------------------------

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)

Reply via email to