8139891: Prepare Unsafe for true encapsulation

[Christian Thalinger]

> On Oct 22, 2015, at 6:31 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> 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.

Yes, me too.  I was worried about a lot of changes in compiler code so I’m really happy to see this is not the case.

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