Currently, Graal directly uses jdk.internal.misc.Unsafe. This means jargraal requires --add-exports=java.base/jdk.internal.misc=jdk.graal.compiler on the command line. Furthermore, it imposes constraints on the evolution of Unsafe. For example, Graal needs to be buildable with the JDK bootjdk. This means, renaming or removing Unsafe methods needs a deprecation cycle of at least one release.
To address the above problems, as many uses of Unsafe as possible in Graal should be replaced with standard API such as VarHandles and Foreign memory access. For the remaining case where performance is critical, a partial copy of Unsafe could be added to JVMCI.
To address the above problems, as many uses of Unsafe as possible in Graal should be replaced with standard API such as VarHandles and Foreign memory access. For the remaining case where performance is critical, a partial copy of Unsafe could be added to JVMCI.