JDK-8334137 : Marlin: replace terminally deprecated sun.misc.Unsafe memory access methods
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: jfx23
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-06-12
  • Updated: 2024-11-27
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.
Other
jfx24Unresolved
Related Reports
Blocks :  
JDK-8340003 - Bump minimum JDK version for JavaFX to JDK 22
Relates :  
JDK-8345121 - JavaFX: WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
Relates :  
JDK-8345127 - Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed
Relates :  
JDK-8331670 - Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
Relates :  
JDK-8334161 - Enable -Werror for javac tasks to fail on any warnings
Relates :  
JDK-8334138 - Suppress removal warnings for sun.misc.Unsafe memory access methods
Description
The Marlin rasterizer uses sun.misc.Unsafe to allocate off-heap memory. All of the memory-access methods in sun.misc.Unsafe have been deprecated for removal by JEP 471 [1] as of JDK 23.

Starting in JDK 24 or 25, using any of these methods will produce a warning. Some time after JDK 25 they will stop working altogether. We need a replacement. There are three options:

1. Use Java arrays, meaning the memory would now be on the heap
2. Use direct NIO buffers for off-heap memory, ByteBuffer.allocateDirect
3. Use FFM as defined in JEP 454 [2]

Option 1 will likely be the least-performant option, and is at least as much work as option 2, so is likely not the best choice.

Option 2 should be pretty straight-forward to implement, at least for the memory allocation and access methods, and should be evaluated for performance.

Option 3 is the best long-term replacement, but will require adopting JDK 22 as the minimum version of JDK for JavaFX. This is something we could consider in the JavaFX 24 or 25 time frame, so this option should also be evaluated.

[1] https://openjdk.org/jeps/471
[2] https://openjdk.org/jeps/454
Comments
[~nlisker] Thanks for your collaboration offer, I am totally open to share the burden; I will focus on peak performance as I wonder if direct address (pointer maths) is faster than layout (struct access); moreover, Arena could be cumbersome to adapt to marlin renderer ThreadLocal context approach ... Let's do it soon, quite overbusy till mid december but I will answer questions and help if you have time to begin the work. Cheers, Laurent
27-11-2024
Sorry [~kcr], I was too busy on many things to start a new sprint on making Marlin (2D & FX) adopt FFM api to deal with native heap, but time is now counted to be delivered by JDK25 release.
27-11-2024
[~lbourges] The uses of the Unsafe OffHeapArray are replaceable with https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/foreign/MemorySegment.html. Specifically, Unsafe.getByte should be replaced by one of these depending on if you access by index or by offset: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/foreign/MemorySegment.html#get(java.lang.foreign.ValueLayout.OfByte,long) https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/foreign/MemorySegment.html#getAtIndex(java.lang.foreign.ValueLayout.OfByte,long) Similarly, for Unsafe.setByte: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/foreign/MemorySegment.html#set(java.lang.foreign.ValueLayout.OfByte,long,byte) https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/foreign/MemorySegment.html#setAtIndex(java.lang.foreign.ValueLayout.OfByte,long,byte) and the same with `int`s. If it helps, we can co-author this fix. I've used FFM in incubation in Java 18 already, thought some things have changed since (e.g., Arena was added).
27-11-2024
JDK 24 now produces a warning by default when running any JavaFX application as a result of our using sun.misc.Unsafe. See JDK-8345121. I will file a build/test bug to pass the `--sun-misc-unsafe-memory-access=allow` flag when running our automated and manual tests until this bug can be fixed such that we no longer use sun.misc.Unsafe. A fix for this bug is highly desirable for JavaFX 24 and will become a critical must-fix for JavaFX 25.
27-11-2024
I was too busy during summer, but I will work on marlin for java2D first to adopt FFM, so option 3, as it is the long-term solution and hope performance will be ss good as manually tuned code on struct-like buffers...
03-10-2024
I propose to bump the minimum JDK for JavaFX to JDK 22, to enable solution 3. Using FFM is the best long term solution and will align with similar plans for Marlin in Java2D.
02-10-2024
NOTE: In JDK-8334161, we will enable warnings-as-errors via "javac -Werror". However, we had to disable it for the javafx.graphics module due to the use of sun.misc.Unsafe, because the warnings generated when using sun.misc.Unsafe cannot be suppressed when building with JDK 22 or later. As part of fixing _this_ bug and removing all uses of sun.misc.Unsafe, we also need to enable "-Werror" for the javafx.graphics module by removing the following block of code from build.gradle: build.gradle: 2270 // FIXME: Remove this setting when JDK-8334137 is fixed 2271 // Disable javac -Werror until we stop using sun.misc.Unsafe 2272 project.ext.disableJavacWerror = true 2273
25-06-2024
[~lbourges] Do you have any thoughts on this?
12-06-2024