As briefly discussed in https://bugs.openjdk.org/browse/JDK-8337853
GlyphLayout has a cache
----
Also GlyphLayout also has a cache .. but it doesn't seem to be a problem ..
even though we clear the cache at 512 entries, the Fonts are collected a long time before we get there
src/java.desktop/share/classes/sun/font/GlyphLayout.java
public static SDCache get(Font font, FontRenderContext frc) {
...
                 } else if (cache.size() >= 512) {
                     cache.clear();
                 }
               cache.put(key, res);


Ah, I see. It uses the java.awt.Font not the sun.font.Font2D. In my test case I created lots of fonts .. but using the same external data, so the java.awt.Font instances were equal.

There's a bug on that too https://bugs.openjdk.org/browse/JDK-8010502

But if it is fixed, this cache will fill up too .. up to its limit. I've tested this and it will happen.
-----

The map is stored via SoftRef but that rarely gets cleared.
 SoftReference<ConcurrentHashMap<SDKey, SDCache>> cacheRef;
The problem is the ConcurrentHashMap

The Font is used in the key (SDKey) and stored in the SDCache value instance
The instance doesn't need it .. it is only used in the constructor and never needed again. So that can be deleted.

Next we need to prevent the key from holding it.
There isn't a WeakConcurrentHashMap so a WeakHashMap with external synchronization needs to be used.