8139891: Prepare Unsafe for true encapsulation

Christian Thalinger christian.thalinger at oracle.com
Thu Oct 22 20:23:46 UTC 2015

> 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

More information about the core-libs-dev mailing list