<div dir="ltr">Hi Wen,<div>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" <a href="https://github.com/openjdk/jdk/blob/ae5e3fdd5922a232c9b48fc846c4fcdc8f2b2645/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java#L197">https://github.com/openjdk/jdk/blob/ae5e3fdd5922a232c9b48fc846c4fcdc8f2b2645/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java#L197</a> instead of getReference.</div><div><br></div><div>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).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 6, 2024 at 4:56 AM wenshao <<a href="mailto:shaojin.wensj@alibaba-inc.com">shaojin.wensj@alibaba-inc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="line-height:1.7;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14px;color:rgb(0,112,192)"><div style="clear:both"><span>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. </span></div><div style="clear:both"><span><br></span></div><div style="clear:both"><span>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. </span></div><div style="clear:both"><span><br></span></div><div style="clear:both"><span>Removal should be after JDK 26.</span></div><div style="clear:both"><br></div><blockquote style="margin-right:0px;margin-top:0px;margin-bottom:0px;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14px;color:rgb(0,0,0)"><div style="clear:both">------------------------------------------------------------------</div><div style="clear:both">发件人：Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>></div><div style="clear:both">发送时间：2024年3月6日(星期三) 17:22</div><div style="clear:both">收件人：mandy.chung <<a href="mailto:mandy.chung@oracle.com" target="_blank">mandy.chung@oracle.com</a>>; core-libs-dev <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>></div><div style="clear:both">主　题：Re: RFD: Can we remove the deprecated internal Unsafe *Object* methods?</div><div style="clear:both"><br></div>On 05/03/2024 22:57, <a href="mailto:mandy.chung@oracle.com" target="_blank">mandy.chung@oracle.com</a> wrote:<br>> These deprecated methods were added to make jsr166.jar to run on <br>> different JDK releases.  I think it's time to remove these deprecated <br>> xxxObject* methods as the renames have been done since JDK 12 for 5 <br>> years.<br><br>Yes, I think they can be removed. They aren't accessible outside of the <br>JDK so nothing should be dependent on them.<br><br>-Alan</blockquote></div></div></blockquote></div>