RFR: 8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases

[Per Minborg]

On Fri, 8 Sep 2023 15:54:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are several methods defined by sun.misc.Unsafe that have standard API equivalents for many years and releases. The change proposed here is to deprecate, for removal, the park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods. Code using these methods should move to LockSupport.park/unpark (Java 5), OperatingSystemMXBean.getSystemLoadAverage (Java 6), and VarHandles xxxFence methods (Java 9).
> 
> The following is a summary of a search of 175973022 classes in 484751 artifacts to get a sense of the usage of these methods.
> 
> - 1290 usages of Unsafe.park. 1195 are libraries that have re-packaged some version of ForkJoinPool, maybe from the jsr166 repo, maybe an older JDK release. In the remaining, only Ehcache stands out with 29 matches. It seems to be one usage but the library seems to copied/shaded into other artifacts.
> 
> - 1322 usages of Unsafe.unpark. 1243 are re-packaged ForkJoinPool. 29 occurrences are Encache, again one usage but the library seems to copied/shaded into other artifacts.
> 
> - 22 usages of Unsafe.getLoadAverage. Most of these are one usage in many published versions of Apache HBase.
> 
> - 339 usages of Unsafe.loadFence, 1057 usages of Unsafe.storeFence, 517 usages of Unsafe.fullFence. A handful of these are libraries with copies of j.u.concurrent, the rest seem to be high performance libraries that support older JDK releases or just haven't been updated to use VarHandles yet.

Currently, all deprecated methods of `Unsafe` are at the end of the file. Is there a specific reason for this other than that they are deprecated? Would it make sense to move down the newly deprecated methods to the end of the file?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15641#issuecomment-1713249729