On 22 Oct 2015, at 21:23, Christian Thalinger <christian.thalin...@oracle.com> wrote:
> >> 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. 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.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 >> >
