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

Andreas L. Delmelle commented on FOP-2525:
------------------------------------------


Thanks for tracing it this far, and the suggested patch! 

Still, I am curious why/whether this would truly solve the memory leak as 
reported. I can see how this would lead to a reduced number of instances that 
would have been considered unequal before the patch, but have you been able to 
ascertain that those instances are now properly collected (i.e. the OOM is not 
just postponed)?
Or would the explanation be that the GC relies on the hashCode() and equals() 
methods to determine which instances can and should be collected? Any idea?

> 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