RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

[David Holmes]

Hi Paul,

On 26/11/2015 7:55 PM, Paul Sandoz wrote:
> Hi,
>
> This is a request for an optimistic review to fork the sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables so that we can evolve the latter e.g. for VarHandles unsafe work
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/

Code changes seem fine.

Tests .... don't think we use testng with any hotspot tests so not sure 
about that part. Also wondering how these tests will access jdk.internal 
once we're using the modular image?

Thanks,
David

> I would like to go through hs-comp since this patch blocks VarHandles work that will also go through hs-comp.
>
> Access tests for both Unsafes are included. The tests are generated using the simple regex-based stream preprocessor (Spp.java) that is also used by nio and it follows the same approach as the nio tests where the generated test code, the test template, and the script to execute the template are in the repo.
>
>
> Core-libs is included because I have added an opt-in command line option (-nel) to Spp.java to not preserve line numbers between the template and generated source code, as sometimes the additional empty lines can be a distraction when browsing the source. When this option is not used it should not result in any changes in output. I also fixed up the TEXT regex pattern so embedded variables work within generic type variable declarations (required for VarHandles which also uses templates to generate source code).
>
>
> The review request is optimistic since this patch is blocked on:
>
>    https://bugs.openjdk.java.net/browse/JDK-8143628
>    C1 LinearScan asserts when compiling two back-to-back CompareAndSwapLongs
>
> which causes test failures on 32 bit fastdebug builds (linux and windows). I am reluctant to modify the tests to workaround (it’s good they found a bug that goes way back to at least 7u1!), and i am hopeful it can be fixed soon (since Roland has found the cause).
>
> Paul.
>