> On Oct 22, 2015, at 6:31 AM, Paul Sandoz <paul.san...@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.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 >
