[OpenJDK 2D-Dev] RFR: 8209113 : Use WeakReference for lastFontStrike for created Fonts

[Sergey Bylokhov]

Looks fine, the only suggestion is to use
   Integer.getInteger(String nm, Integer val)
instead of
   try{Integer.parseInt}catch{}



On 11/27/19 1:42 pm, Phil Race wrote:
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8209113 <https://bugs.openjdk.java.net/browse/JDK-8209113>
> 
> Webrev: http://cr.openjdk.java.net/~prr/8209113/
> 
> 
> This fix is intended to update the ergonomics of font glyph caching which
> uses off-java heap native memory and so is not considered by garbage collection.
> The update has become needed as the GCs have changed to favour performance
> over reclaimation of resources as heaps have grown very large and client
> (and server) applications are being run with VMs with server focused ergonomics
> 
> Also note that this is actually more of a server problem than a client one,
> since a UI client usually uses a small number of fonts.
> Servers are often processing thousands of documents that contain custom
> fonts - typically all different - and reclaiming these more promptly will free
> up the native memory used by the font rasterizer data structures, and the
> temporary font files they use as well as the memory used to cache glyph images.
> 
> Each font instance has its own cache of strikes which in turn reference the native
> images, so there is no global management.
> This fix does not go so far as to look for a way to limit the amount of memory used
> by each font which would require some major surgery to the current GC managed
> approach.
> So the changes here are to allow more prompt clearing of references and
> recollection of the native memory by each font.
> 
> The important change is in Font2D where there is a SoftReference to the last used strike.
> https://bugs.openjdk.java.net/browse/JDK-8209113 observes that the reluctance of
> the VM to clear this SoftReference causes delays in freeing all of the resources.
> Now the code is updated to conditionally use a WeakReference.
> Using a WeakReference is controlled from the code in SunFontManager based
> on whether this is a temporary "created" font and how many temp fonts are
> being created. So this should not affect system fonts at all, and should also not
> affect an app using a small number of custom fonts while helping the server case a lot.
> 
> The other change is that FontStrikeDisposer no longer holds a reference to the Font2D.
> It needed it solely to call back to remove its strike from the Map of Strikes once
> it was collected. Now it holds a reference directly to the Map and its dispose
> method does the removal without needing to ask the Font2D.
> This does not make a lot of difference, but every bit helps.
> 
> Instrumented testing shows that together, for at least some workloads, these
> changes help smooth out native memory usage by making collection of temporary
> fonts more prompt. There are doubtless pathological cases that are still a problem
> and if you want to hold concurrent references in your application to 100,000 java.awt.Font
> instances, all of which are being used, then you need to size your server to cope ...
> 
> But this will be helpful in the typical ephemeral font case.
> 
> Random ideas that could go further but are out of scope of this fix are
> 1) An explicit dispose() method on a Font.
>      Problems here include the semantics of this for System fonts, backwards compatibility
> and ensuring no one is still using it. Even if the implementation is limited to clearing
> just the native memory usage these can still be issues and if you remove the backing
> file then you can never re-create it.
> 2) Some automatic internal per-font limitation on the amount of storage a Font uses.
>    Here there would also need to be some way to ensure code was locked out from using
>    it whilst this was happening. It may be more doable but it would mainly help the cases
>   where applications used the same font extensively. Not the case where thousands of
>   fonts are used minimally.
> 3) Looking to see if two fonts are actually identical. If a temp font is created from
>    a byte stream and the byte stream is identical to some other temp font then really
>    these are the same. If you have thousands of such shareable fonts this would be a big
>   win. But we'd need to have a way to locate all such temp fonts (that did not itself
> prevent their prompt collection) and quickly compare them - probably a hash calculated
> when they were created - and then do a full comparison when the hashes match.
> But if shareable fonts are rare, it won't help at all. However it might be worth exploring
> some day.
> 
> -phil.
> 
> 


-- 
Best regards, Sergey.