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

Paul Sandoz paul.sandoz at oracle.com
Mon Jan 19 15:31:37 UTC 2015


On Jan 19, 2015, at 6:48 AM, David Holmes <david.holmes at oracle.com> wrote:

> 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.

Thanks for the heads up. I would like to keep the link to the file, as it is an unusual outlier (what appears to be an unused private static method) and it is not obvious why it is there. I presume it needs to hang off some Java class so some additional reasoning would also be useful, like this method gets hooked up to the itable of an interface for access control error reporting reasons.


> 
>> 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 ?
> 

Because the Unsafe native methods are called getXXX and putXXX and i wanted a clear correspondence to those names rather than association with the C++ method names. I held off changing the C++ method names themselves.


>> 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.
> 

Ok, i will remove and see what happens.

Paul.


More information about the hotspot-runtime-dev mailing list