RFR 8068975: Remove deprecated methods on sun.misc.Unsafe and clean up native implementation

[David Holmes]

Hi Paul,

On 16/01/2015 2:55 AM, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8068975-unsafe-cleanup/webrev/
>
> This "forest" webrev cleans up sun.misc.Unsafe.java and hotspot/src/share/vm/prims/unsafe.cpp.
>
> In sun.misc.Unsafe all deprecated methods are removed.

Looks good. One nit:

  924     private static void throwIllegalAccessError() {
  925         // This method is linked/verified in:
  926         //   hotspot/src/share/vm/memory/universe.cpp
  927         // and assigned to:
  928         //   Universe::_throw_illegal_access_error
  929         throw new IllegalAccessError();
  930     }

The comment seems excessively detailed - the second part is about to 
become incorrect due to 8068162 :) I would just keep the link to the 
file if you think it warranted.

> In unsafe.cpp one array of native method declarations is used and
> unused methods are removed.

The switch between the SetMemory and SetMemory2 implementations could 
have used a headsup. Took me a while to realize as of 1.7 that was how 
the mapping was defined. :)

Why did you change DECLARE_GETSETxxx to DECLARE_GETPUTxxx when the 
method name is "set" in this file ?

> There is one remaining TODO:
>
>   136 // Externally callable versions:
>   137 // (Use these in compiler intrinsics which emulate unsafe primitives.)
>   138 jlong Unsafe_field_offset_to_byte_offset(jlong field_offset) {
>   139   return field_offset;
>   140 }
>   141 // TODO The following three methods are not used, can they be removed?
>   142 jlong Unsafe_field_offset_from_byte_offset(jlong byte_offset) {
>   143   return byte_offset;
>   144 }
>   145 jint Unsafe_invocation_key_from_method_slot(jint slot) {
>   146   return invocation_key_from_method_slot(slot);
>   147 }
>   148 jint Unsafe_invocation_key_to_method_slot(jint key) {
>   149   return invocation_key_to_method_slot(key);
>   150 }
>
> I don't quite know what the above methods are for, but only the first is used, and it's a no-op. Can anyone provider more context for these?

Sorry I can't help there.

Thanks,
David

>
> Testing wise, so far, i have only identified one failure for an internal JDK test that relies on one of the deprecated methods (looked up via reflection), which i will update independently to this review.
>
> Paul.
>