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.
