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

Chris Hegarty chris.hegarty at oracle.com
Thu Oct 22 14:28:02 UTC 2015

As part of the preparation for JEP 260 [1], Unsafe needs to be separable from the base module [2], so it can be exported by a new, yet to be defined, jdk.unsupported module, and have a separate evolution policy that is not exposed. That is, the JDK needs an internal Unsafe that can be evolved and added to in future releases, while maintaining the existing Unsafe API that developers are using.

Many uses of Unsafe are for performance reasons. Any changes made should preserve the current performance characteristics. To achieve this the existing Unsafe intrinsic candidate methods should remain intrinsic candidate methods. The VM can provide aliases for these intrinsics so they are common to both the internal and sun.misc versions of Unsafe.

The JDK implementation will be updated to use the new internal version of Unsafe.

For the purposes of making progress, I think this work can be split into several steps:

  1. Create the new internal Unsafe class and provide intrinsic support for both.
  2. Update existing, and possibly add new, tests to use the new internal Unsafe. Some tests may need to be duplicated, or reworked, to test both versions of Unsafe.
  3. Update the Unsafe usages in the JDK so that there is no longer any dependency on sun.misc.Unsafe.

To this end I've put together a webrev containing the changes required for step 1. It contains

http://cr.openjdk.java.net/~chegar/unsafe_phase1/

All JPRT hotspot and core libraries tests pass.

I have most of the work for steps 2 and 3 done, but some discussion and clean up is required. It also increase the level of difficult to review the changes in phase 1, which is mostly what I'd like to get agreement on first.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8132928 [2] https://bugs.openjdk.java.net/browse/JDK-8139891

More information about the core-libs-dev mailing list