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

[Maurizio Cimadamore]

On Mon, 24 Jun 2024 18:04:38 GMT, Maurizio Cimadamore <mcimadamore 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.
>
> 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