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.
