Hi Wen, I think this change is for jdk.internal's Unsafe (JDK 9+) instead of for sun.misc's Unsafe. The sun.misc.Unsafe's methods have stayed "getObject" https://github.com/openjdk/jdk/blob/ae5e3fdd5922a232c9b48fc846c4fcdc8f2b2645/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java#L197 instead of getReference.
Also the preferred way since JDK 9 to access these operations is via java.lang.invoke.VarHandle, which exposes more fine-grained access modes like plain/acquire-release/compareAndExchange, all of which are backed by the newer jdk.internal's Unsafe. I think the main reason JSR 166 (java.util.concurrent) code uses Unsafe directly is that it wants to avoid an early startup dependency on VarHandle (like in the case of your decimal toString optimization). On Wed, Mar 6, 2024 at 4:56 AM wenshao <shaojin.we...@alibaba-inc.com> wrote: > Many libraries use Unsafe to improve performance, especially in many > performance-critical scenarios of big data, such as Apache Flink/Apache > Arrow, etc. Direct removal will make it difficult to adopt the new version > of JDK. > > It is recommended to use it similar to JEP 396, which needs to be opened > through parameters before it can be used and configured. The JVM startup > parameter "--illegal-unsafe=warn" can be enabled. > > Removal should be after JDK 26. > > ------------------------------------------------------------------ > 发件人：Alan Bateman <alan.bate...@oracle.com> > 发送时间：2024年3月6日(星期三) 17:22 > 收件人：mandy.chung <mandy.ch...@oracle.com>; core-libs-dev < > core-libs-dev@openjdk.org> > 主 题：Re: RFD: Can we remove the deprecated internal Unsafe *Object* methods? > > On 05/03/2024 22:57, mandy.ch...@oracle.com wrote: > > These deprecated methods were added to make jsr166.jar to run on > > different JDK releases. I think it's time to remove these deprecated > > xxxObject* methods as the renames have been done since JDK 12 for 5 > > years. > > Yes, I think they can be removed. They aren't accessible outside of the > JDK so nothing should be dependent on them. > > -Alan > >
