RFR: 8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation [v2]

[Phil Race]

On Mon, 24 Jun 2024 22:25:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Migrate font code from jdk.internal.misc.Unsafe to using FFM.
>> This reduces the coupling between the java.desktop module and the internals of the java.base module.
>> 
>> The code being changed here is not particularly performance sensitive, and it is not executed in the most common cases.
>> The main impact performance-wise is a total of around 37ms in initialisation costs on my x64 macbook.
>> A minimal program that just draws a string to an image - does not even put up a window - runs at around 690-700ms.
>> There's variability in that number and the overall time for a JDK without the change is around (660-670ms)
>> In the small test, this is the first and only use of FFM, so the one-off part cost should move elsewhere when FFM starts
>> to be used earlier in the JDK itself.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8334495

> DId ffm team check from where that slow down come from? is it expected to lose 5%?
> 
> > In the small test, this is the first and only use of FFM, so the one-off part cost should move elsewhere when FFM starts
> > to be used earlier in the JDK itself.
> 
> So the changed code path will work as before (w/o slowdown) if the #15476 will be touched by the test? and slow down will occur if "sun.font.layout.ffm" will be set to false? Just would like to confirm that we will not get "multiplication of slowdowns" for each ffm usage.

Well there's going to be some fraction of it in order to create the VarHandles but
the initialisation cost of the classes used by the FFM implementation is
one time even if both are used, so it just depends who gets there first as to where
it is seen, and if both are used, then only one will take that initialisation cost.
However the layout code creates downcall and upcall stubs too, so it has a bigger
one time cost than this code.
In other words if hypothetically :
- 30 ms one time init machinery cost for this cache code
- 80 ms one time init machinery cost for the layout FFM code
and this code is executed first, then layout would see a 50 ms cost,
or if the layout code is executed first then I'd expect to see zero machinery init cost here.

There's still *some* cost for each VarHandle etc. Executing code isn't free.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19777#issuecomment-2190048299