Lars J commented on FOP-2525:

I'd like to second this - the patch rocks.

We have a web application that does a large amount of PDF generation, and we 
recently migrated to Apache FOP and immeditely started seeing memory problems.  
I've profiled our application during PDF generation and as Andreas has reported 
we saw large numbers (millions!) of instances of GlyphPositioningTable$Value 
and GlyphPositioningTable$PairValues accumulating in the heap that would not be 
cleaned up even by a forced GC.

Applying David's patch resolved the issue - our heap usage normalised and 
further memory profiling showed no more GlyphPositioningTable objects among the 
biggest memory consumers.

Note that we are also using TTF fonts, but not in TTC files.

> 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

Reply via email to