JDK-8173799 : Use sun.java2d.font.reftype in Font2D ?
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 9,10
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • Submitted: 2017-02-02
  • Updated: 2019-11-27
  • Resolved: 2019-11-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
Relates :  
Description
At Google, production users on Linux have trouble with many font creations from InputStreams resulting in many files accumulating in /tmp such as
+~JF14280372815902140030.tmp

Those files are retained via a SoftReference.  We have experimented with replacing those SoftReferences with WeakReferences in Font2D.java and SunLayoutEngine.java as is done in StrikeCache if sun.java2d.font.reftype is set to "weak", and this seems to mitigate the problem, although of course no one has a real solution to the java resource finalization problem.  Is there some way to "close" fonts that we're missing?

Below is a simple program that demos this:

import java.awt.Font;
import java.io.FileInputStream;

public class FontFileLeak {
    public static void main(String[] args) throws Exception {
        for (;;) {
            try (FileInputStream fis = new FileInputStream(
                "/usr/share/fonts/truetype/droid/DroidSerif-Bold.ttf")) {
                Font thingy = Font.createFont(Font.TRUETYPE_FONT, fis);
                Font f = thingy.deriveFont(Font.PLAIN, 24);
            }
        }
    }
}

... and do ls /tmp/*.tmp | wc to "monitor progress"
Comments
I think the issue in JDK-8209113 points to something we can improve which I believe will help this case. Closing as a duplicate.
27-11-2019

I made another unsuccessful effort to poke at this. In jdk11 my demo program still produces thousands of temp files. As an experiment I tried changing all occurrences of SoftReference in font-related code to WeakReference, but it didn't really seem to help. Maybe the GC has changed or maybe the Reference Handler thread isn't keeping up. The fundamental problem remains (and is worse at Google, where local disk in production is a limited resource). There ought to be an explicit close offered to users that will deterministically delete the temp files, or the size of the cache should be limited somehow. Consider giving this bug a better summary.
22-05-2018

The only SoftReference in Font2D is to the Strike to keep that around. It is not apparent to me why the Font2D soft referencing the strike should stop the Font2D being collected when it is no longer referenced. Can you provide any more information on what you are seeing for this case ? Perhaps it occurs only in conjunction with the second case below in which case Font2D is not an issue ? The SunLayoutEngine one looks like an issue .. we have a SoftReference to the cache and the cache key is a class which is basically a struct, one of whose members is the Font2D. So if a font is loaded via createFont and then layout is invoked, it seems like it could hang around for a long time .. it really matters only for the loaded fonts. That code in SunLayoutEngine needs reworking in general but I expect changing that to a WeakReference would help reduce the retention. Note that WeakRefs are collected almost immediately and SoftRefs almost never .. so the problem could flip to a performance one. That needs to be checked. If it is an issue we could create a separate weak cache for loaded fonts.
06-10-2017