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