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. Thanks Chris > On 22 Oct 2015, at 16:28, Chris Hegarty <chris.hega...@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
