On Mon, 24 Jun 2024 18:04:38 GMT, Maurizio Cimadamore <mcimadam...@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.
>
> src/java.desktop/share/classes/sun/font/StrikeCache.java line 151:
>
>> 149:
>> 150: @SuppressWarnings("restricted")
>> 151: static final float getGlyphXAdvance(long ptr) {
>
> now, I'm not an expert of this code, but I notice that you have accessors
> that seem to take a bare `long` instead of `MemorySegment`. Have you tried
> pushing segments deeper in the implementation? That way I think you could
> completely auto-generate this code using jextract. (of course what you have
> is not bad - I'm mostly trying to see if there's a way to get there w/o all
> these calls to `MemorySegment::reinterpret`).
To be clear - I'm assuming the `ptr` parameter comes from a single native call.
That call returns a pointer to a struct, or maybe an array of structs. If so,
we could reinterpret right after the native call, with the right size (the
number of structs returned by the native call), and then all the accessors will
be just "plain" memory segment accessors, no need to reinterpret (as the
segment will already have the correct size).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19777#discussion_r1651431857
