8139891: Prepare Unsafe for true encapsulation

Paul Sandoz paul.sandoz at oracle.com
Thu Oct 22 16:31:45 UTC 2015


Hi Chris,

This looks like a good first step. I am sure hotspot devs will have more concrete review comments, but i like the way the method aliasing (copying the same technique StrictMath -> Math) avoids any changes to the intrinsics, thus the changes are much more localized.

It may be worth having some fast debugging output for the aliasing in case internal refactoring messes things up.

Paul.

> On 22 Oct 2015, at 07:28, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 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
>   - 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/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