New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
Remi Forax
forax at univ-mlv.fr
Mon May 6 16:47:18 UTC 2024
Hello,
I think this JEP is a little too optimistic,
I've spent the last two weeks trying to replace all the usages of Unsafe with the foreign memory API in my code (public or private) and there are some rough edges.
The main blocker in my case if that creating an Arena ranges between slow for a confined arena to very very slow for a shared arena.
Here is a JMH benchmark [0] to understand the issue:
// Benchmark Mode Cnt Score Error Units
// ArenaBenchmarks.newArray avgt 5 2.529 ± 0.013 ns/op
// ArenaBenchmarks.newSegmentAuto avgt 5 409.666 ± 210.548 ns/op
// ArenaBenchmarks.newSegmentConfined avgt 5 82.353 ± 0.263 ns/op
// ArenaBenchmarks.newSegmentShared avgt 5 7094.796 ± 297.683 ns/op
// ArenaBenchmarks.newSegmentWrap avgt 5 6.454 ± 0.113 ns/op
// ArenaBenchmarks.newUnsafeMemory avgt 5 22.753 ± 0.023 ns/op
// ArenaBenchmarks.newUnsafeMemoryWithInit avgt 5 71.563 ± 0.827 ns/op
It compares the cost of allocating an array of bytes either in Java (newArray), using different arenas (newSegmentAuto, newSegmentConfined, newSegmentShared) or using sun.misc Unsafe (newUnsafeMemory, newUnsafeMemoryWithInit).
As an example, the migration of OffHeapIntBuffer is not really realistic because of the performance cost of Arena.ofShared() is 300x compared to Unsafe.allocate().
I'm not saying the foreign memory API is not amazing, it is, I was able to replace all the codes using Unsafe based on mmap to use the memory segment without any performance loss but there are still some rough edges and I think we should acknowledge that.
regards,
Rémi
[0] https://github.com/forax/memory-mapper/blob/master/src/main/java/com/github/forax/memorymapper/bench/ArenaBenchmarks.java
----- Original Message -----
> From: "mark reinhold" <mark.reinhold at oracle.com>
> To: "Ron Pressler" <ron.pressler at oracle.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.org>
> Sent: Friday, May 3, 2024 5:11:42 PM
> Subject: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
> https://openjdk.org/jeps/471
>
> Summary: Deprecate the memory-access methods in sun.misc.Unsafe for
> removal in a future release. These unsupported methods have been
> superseded by standard APIs, namely the VarHandle API (JEP 193,
> JDK 9) and the Foreign Function & Memory API (JEP 454,
> JDK 22). We strongly encourage library developers to migrate from
> sun.misc.Unsafe to supported replacements, so that applications can
> migrate smoothly to modern JDK releases.
>
> - Mark
More information about the jdk-dev
mailing list