8139891: Prepare Unsafe for true encapsulation (original) (raw)

John Rose john.r.rose at oracle.com
Fri Oct 23 01:06:27 UTC 2015

On Oct 22, 2015, at 7:28 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

To this end I've put together a webrev containing the changes required for step 1. It contains - the intrinsic aliasing, - the new internal Unsafe ( copy of sun.misc.Unsafe ), - reverts sun.misc.Unsafe to, almost, its 1.8 API, - minimal test and implementation updates, since there some usages of unaligned access that is new in the 1.9. http://cr.openjdk.java.net/~chegar/unsafephase1/ <http://cr.openjdk.java.net/~chegar/unsafephase1/>

Looks good.

The name jvm.internal.misc.Unsafe is begging to be split and renamed. See http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf <http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf> for a good example of how to put parts of Unsafe into logical buckets. But that is a task for another day.

The VM changes will have to happen a second time when jvm.internal.misc.Unsafe is refactored. It is not clear how to pivot the current changes to prepare for that, since the naming conventions in the JVM are very explicit about the concrete names of intrinsics.

One suggestion: I think the Method:: is_unsafe_alias is not a useful API point. I suggest making that function be a local, static helper for init_intrinsic_id. That way it doesn't have to show up in method.hpp, and that file won't have to be edited when we refactor.

For a similar reason, I suggest changing the comments in library_call.cpp so that they become more vague about the location of Unsafe:

-// public native void sun.misc.Unsafe.putOrderedObject(Object o, long offset, Object x); +-// public native void [sun|jdk.internal].misc.Unsafe.putOrderedObject(Object o, long offset, Object x); ++// public native void Unsafe.putOrderedObject(Object o, long offset, Object x);

That way the file won't have to be re-edited if we refactor. Same point for memnode.hpp and unsafe.cpp (and maybe other spots which say too much?). It's already good in heapDumper.cpp. In globals.hpp it's half good and half not-good.

BTW, I think the name SystemDictionary::internal_Unsafe_klass is future-proof in this respect.

Thanks for taking this on!

— John

P.S. Just for the record, the native-heap-only memory accessors should not be intrinsics, since they can be trivially derived from the normal two-argument accessors:

More information about the core-libs-dev mailing list