JDK-8318364 : Add an FFM-based implementation of harfbuzz OpenType layout
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-10-17
  • Updated: 2024-06-25
  • Resolved: 2023-11-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 22
22 b25Fixed
Related Reports
Relates :  
JDK-8331735 - java.lang.Thread.scopedValueBindings contains garbage when crashing in java/awt/font/TextLayout/FontLayoutStressTest during GC
Relates :  
JDK-8330746 - [Linux/aarch64] java/awt/font/GlyphVector/LayoutCompatTest.java files differ byte offset=9891
Description
The FFM API JEP https://openjdk.org/jeps/454 is now implemented in JDK 22.
It can be used in place of existing JNI-based native access in the JDK.
The java.desktop module has a very large investment in JNI, but we can slowly start to adopt FFM where it makes sense.
One such case is the JDK's use of harfbuzz for OpenType layout.
This particular case has the potential to benefit from FFM for better code and better performance, as well as exploring the limits of what FFM can do and inform future improvements and direction.
Comments
In our CI testing of client at Oracle (which does does not use debug/fastdebug) this test runs in < 2 seconds on Windows Server 2019.
10-01-2024
OK [~mbaesken]. I wonder if the issue is just that we know client doesn't work fully in debug mode on Windows. Period. Depending on .. code path .. whatever .. you can get assert popups that require user interaction. We've generally told people to "not do that", because we have no time to fix the issues. You might want to manually run on windows with debug binaries to check this,
04-01-2024
Hi [~prr] on Linux or macOS the test takes ~ 20s (fastdebug binaries) . Only on Windows it is slow and shows the mentioned timeouts. I navigated through the last few days of test results and there it always failed on Windows (issue can be seen on at least 2 test machines).
03-01-2024
[~mbaesken] I would expect this test to take maybe just 5-10 seconds, and a fastdebug binary should not be that much slower. Something likely not directly related to the API is being tested maybe the issue. Like the sub-process not terminating properly. I interpret what you say as meaning that it sometimes passes. How long does it take when it passes ? The 10 seconds I expect, or somewhere close to 180s ?
02-01-2024
Since the 8318364 has been pushed to jdk-head, we see a lot of timeouts in the introduced java/awt/font/GlyphVector/LayoutCompatTest.java test. Those occur on some of our Windows test machines, fastdebug binaries are used there (so far, no timeouts in this test on other platforms). Stacks in the timeout case shows this : at java.lang.ProcessImpl.waitForInterruptibly(java.base@23-internal/Native Method) at java.lang.ProcessImpl.waitFor(java.base@23-internal/ProcessImpl.java:569) at LayoutCompatTest.forkAndWait(LayoutCompatTest.java:211) at LayoutCompatTest.main(LayoutCompatTest.java:113) at java.lang.invoke.LambdaForm$DMH/0x0000029890006c00.invokeStatic(java.base@23-internal/LambdaForm$DMH) at java.lang.invoke.LambdaForm$MH/0x0000029890008000.invoke(java.base@23-internal/LambdaForm$MH) at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base@23-internal/Invokers$Holder) at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base@23-internal/DirectMethodHandleAccessor.java:154) at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base@23-internal/DirectMethodHandleAccessor.java:103) at java.lang.reflect.Method.invoke(java.base@23-internal/Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.lang.Thread.runWith(java.base@23-internal/Thread.java:1583) at java.lang.Thread.run(java.base@23-internal/Thread.java:1570)
29-12-2023
Changeset: f69e6653 Author: Phil Race <prr@openjdk.org> Date: 2023-11-21 17:46:29 +0000 URL: https://git.openjdk.org/jdk/commit/f69e6653f86a7dd781db6c8523f114c0d3f7ccbc
21-11-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/15476 Date: 2023-08-29 22:04:40 +0000
18-10-2023
There are some interesting challenges here - harfbuzz needs to make multiple call backs to client-provided functions. In FFM (and JNI) this means Java upcalls. But FFM has potential to be better performing in these cases - JNI objects need to be passed around. We can't do this directly so bound method handles and ScopedValue are used. The latter is still preview in JDK 22 but it is not exposed in any way to applications or API so can be used. - We should run the JNI and FFM implementations side-by-side. This does limit some things we might otherwise want to consider. Notably libharfbuzz is embedded inside libfontmanager so we can't call the harfbuzz functions directly, having to call intermediate JDK-specific exported functions. Some day we should revisit this. - Performance of the FFM code can be higher than the JNI code, except for very short-lived applications where that is offset by startup and warmup costs. For now I think I've tuned this as much as I can and the trade-off is acceptable.
17-10-2023