8139891: Prepare Unsafe for true encapsulation

[Chris Hegarty]

On 22 Oct 2015, at 21:23, Christian Thalinger <christian.thalinger at oracle.com> wrote:

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

Thanks for looking at this Christian.   An earlier local version of this
change did modify a lot of compiler code, but I’m relatively happy
with how this turned out.

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

Possibly. CheckIntrinsics, in a fast debug build, will catch if there
is a mismatch.   I hope to also add some new tests to the hotspot
forest to make sure Unsafe continues to work as expected.

-Chris.

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