+1.
Thanks,
Jay
On 05/12/19, 10:14 AM, "2d-dev on behalf of Philip Race"
<2d-dev-boun...@openjdk.java.net on behalf of philip.r...@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.
>>
>>
>
>
