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