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

Maurizio Cimadamore mcimadamore at openjdk.org
Mon Jun 24 18:10:13 UTC 2024


On Tue, 18 Jun 2024 20:31:58 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.

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`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19777#discussion_r1651425494


More information about the client-libs-dev mailing list