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)