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

[Phil Race]

I made the one change suggested :

http://cr.openjdk.java.net/~prr/8209113.1

and pushed with that ..

-phil.

On 12/4/19 8:54 PM, Jayathirth Rao D V wrote:
> +1.
>
> Thanks,
> Jay
>
> On 05/12/19, 10:14 AM, "2d-dev on behalf of Philip Race" <2d-dev-bounces at openjdk.java.net on behalf of philip.race at oracle.com> wrote:
>
>      
>      That is equivalent, just syntactic, so no issue there.
>      Any other reviewers ? This needs two.
>      
>      -phil.
>      
>      On 12/4/19, 2:39 PM, Sergey Bylokhov wrote:
>      > 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.
>      >>
>      >>
>      >
>      >
>      
>
>