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

Coleen Phillimore coleen.phillimore at oracle.com
Thu Dec 3 02:58:02 UTC 2015

I finally had a chance to look at this.  Why are there pages of commit 
messages in these webrevs?


+static JNINativeMethod sun_misc_Unsafe_methods[] = {

This looks like a copy of the list of methods that we already have.

+static JNINativeMethod jdk_internal_misc_Unsafe_methods[] = {

Can you just have:

+static JNINativeMethod sun_misc_Unsafe_methods[] = methods; +static 
JNINativeMethod jdk_internal_misc_Unsafe_methods[] = methods; ???


I don't see the benefit of testng here.  You probably already have 
Assert in our test library.


Is this script and template how these tests were generated?   It doesn't 
seem like it needs to be checked in (and is missing copyright).

Maybe since the tests are stressing the compilation characteristics of 
the unsafe API, these tests belong in the test/compiler/unsafe 
directory.  Maybe the compiler group doesn't mind slogging through 
testng to find bugs.


On 12/2/15 3:54 AM, Paul Sandoz wrote:
> Hi Coleen,
>> On 1 Dec 2015, at 20:42, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>> Would i be correct in stating that the HotSpot runtime team is taking a conservative position and does not want to deal with such a library, contrary to other areas of the JDK?
>> Yes.  That is correct.  We don't need more frameworks that hinder getting to the java command line for the class file.  It's time consuming enough with jtreg.
> So is the real underlying reason is you don’t want to run the tests *locally* with jtreg at all? (Note that jtreg spits out a script that one can use to re-run faster.)
> At some point later these tests will be even more dependent on jtreg because they have an internal dependency on Unsafe and jtreg will wire up things correctly to bust through the encapsulation, as these are white box tests.
>>> Sorry to push back, but I don’t agree with that position (if correct). I am reluctant to change the tests. Please don’t think that complete pigheadedness on my part :-) I just don’t think it’s the right thing to do.
>>> If the HotSpot runtime team will not accept the use of TestNG then I suppose I could unblock by proposing to move the tests to the JDK repo, which I would also be reluctant to do since they caught an issue lying dormant for at least 8 years on certain platforms (not covered by the core testset) that existing hotspot tests never caught.
>> Can you repost the whole webrev to hotspot-dev ?  I didn't see the original to see why these tests require the testng framework and cannot be written as simple regression tests.  If they have to be very complex, maybe they belong in a different test directory that has support and tolerance for this complexity.  Maybe you can write a small regression test for the hotspot/test/runtime test and put the rest somewhere else.  Again, this is in the abstract.  I don't have the webrev.
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/webrev/>
> It’s not just about complexity, it’s also about better test code, consistency and reporting.
> It feels strange to be arguing for the utilisation of a unit test library. Most of the world moved on over 15 years ago :-) and most of the JDK has already moved on.
> Paul.

More information about the hotspot-dev mailing list