Runtime uses jvm methods that are depreciated and may be soon removed

Compiler version

At current main - 1ea177df6d, and also previous versions.

The problem

The problem is caused by usage of Unsafe.objectFieldOffset in runtime. When compiling the compiler on JVM 18, the following errors appear:

sbt:scala3> testCompilation
[error] -- Error: /Users/srodziewicz/Documents/Projects/VirtusLab/dotty/library/src/scala/runtime/LazyVals.scala:103:19 
[error] 103 |    val r = unsafe.objectFieldOffset(clz.getDeclaredField(name))
[error]     |            ^^^^^^^^^^^^^^^^^^^^^^^^
[error]     |method objectFieldOffset in class Unsafe is deprecated since : see corresponding Javadoc for more information.
[error] -- Error: /Users/srodziewicz/Documents/Projects/VirtusLab/dotty/library/src/scala/runtime/LazyVals.scala:110:19 
[error] 110 |    val r = unsafe.objectFieldOffset(field)
[error]     |            ^^^^^^^^^^^^^^^^^^^^^^^^
[error]     |method objectFieldOffset in class Unsafe is deprecated since : see corresponding Javadoc for more information.

It’s not a problem per se, as we don’t use this version of JDK on compiling. But, per the documentation:

The guarantee that a field will always have the same offset and base may not be true in a future release. The ability to provide an offset and object reference to a heap memory accessor will be removed in a future release. Use {@link java.lang.invoke.VarHandle} instead.

And we heavily rely on this feature in the current and the new lazy vals implementation. It’s not a problem now, but soon lazy vals can stop working on new jvms as we don’t have any guarantee on their stability.

Proposal

Use MethodHandles to execute the Unsafe methods if the currently running jvm version == 1.8. In other case, use the VarHandles. It’s a pretty complex approach and there may be another simpler solution.

[smarter]

I think it’s important for the compiler to compile on every jdk people might use, so a PR that would silence the deprecation would be welcome.

[smarter]

What we could do is 1) under -release >= 9, use VarHandle properly 2) under -release 8, keep using unsafe but have a (potentially slower) runtime fallback if the method is not available