3 ms·
Did you read the JEP? << Over the past several years, we have introduced two standard APIs that are safe and performant replacements for the memory-access meth
by throwaway2037 3y ago
Did you read the JEP?
<<
Over the past several years, we have introduced two standard APIs that are safe and performant replacements for the memory-access methods in sun.misc.Unsafe:
java.lang.invoke.VarHandle, introduced in JDK 9, provides methods to safely and efficiently manipulate on-heap memory: fields of objects, static fields of classes, and elements of arrays.
java.lang.foreign.MemorySegment, introduced in JDK 22, provides methods to safely and efficiently access off-heap memory (sometimes in cooperation with VarHandle).
These standard APIs guarantee no undefined behavior, promise long-term stability, and have high-quality integration with the tooling and documentation of the Java Platform (examples of their use are given below). Given the availability of these APIs, it is now appropriate to deprecate and eventually remove the memory-access methods in sun.misc.Unsafe.
>>
- bremac 3y agoAs the comment you replied to indicates, both of those APIs perform bounds-checking. In certain tight loops, this can add up to quite a bit of overhead [1]. However, it's not documented, but if you really know what you are doing you can convince the JIT to elide the bounds checks for MemorySegments [2]. [1] https://mail.openjdk.org/pipermail/panama-dev/2023-July/019363.html https://mail.openjdk.org/pipermail/panama-dev/2023-July/0193... [2] https://mail.openjdk.org/pipermail/panama-dev/2023-July/019487.html https://mail.openjdk.org/pipermail/panama-dev/2023-July/0194...
- kaba0 3y agoAs pron mentioned, you can use the internal unsafe API without bound checks, you just need a flag for that