[jira] [Updated] (FOP-2525) Memory leak present when using Truetype Collection (.ttc)

["Andreas L. Delmelle (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FOP-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas L. Delmelle updated FOP-2525:
-------------------------------------
    Attachment: FOP-2525.patch


Patch to FOP trunk, following David's suggestion. hashCode() aligned with the implementations already used elsewhere in FOP's codebase.

It would be great if the OP (Jeremy) could also independently verify and confirm that this fixes the issue on his end, prior to committing.

Unless anyone objects, I will commit this change by the end of the week.

> 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
>         Attachments: FOP-2525.patch
>
>
> 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)