8139891: Prepare Unsafe for true encapsulation

Christoph Engelbert me at noctarius.com
Thu Oct 22 14:48:31 UTC 2015

Hey Chris,

I don’t like to say it but it sounds very wrong to have another Unsafe like thinggy in the future instead of providing public alternatives right from the start. I agree it might be a faster to just write adapter classes and I really don’t like to repeat what I said in the past but why should Oracle be able to write fast Java code than the public? It just doesn’t make sense to me.

Just to clarify, I don’t want to start another fight I just want to make sure I understand the reason for another class like Unsafe and why it seems like that there is another move to hide performance relevant details from Java developers around the world.


> On 22 Oct 2015, at 16: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