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

[Paul Sandoz]

> On 3 Dec 2015, at 14:16, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> 
> On 12/3/15 4:51 AM, Paul Sandoz wrote:
>>> On 3 Dec 2015, at 03:58, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>> 
>>> 
>>> I finally had a chance to look at this.  Why are there pages of commit messages in these webrevs?
>>> 
>> Not sure, it seems to be a bug with webrev (and may be a consequence of the interaction with patch queues, but i have not had time to dig into why this occurs).
> 
> I think this is a bug with the interaction with your patch queues. Before you send stuff out for review (at least to the hotspot lists), can you export the patch into a clean repository so that we don't have to find the changes in pages of stuff?

(With 4 or so patches concurrently in flight for various issues across jdk and hotspot of hs-comp that approach does not scale very well.)

Thanks to Claes who proposed a workaround: remove the use of —follow in webrev.ksh (and in ~/.hgrc if present). I updated the webrevs.


>> 
>>> You probably already have Assert in our test library.
>>> 
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/webrev/test/runtime/Unsafe/generate-unsafe-access-tests.sh.html
>>> 
>>> Is this script and template how these tests were generated?
>> Yes, it’s the same pattern as used in nio tests. If we evolve the tests we will edit the template and run the generation script rather than potentially editing 18 files.
> 
> That seems ok, as long as running the script isn't part of the testing.

Yes, it’s separate, don’t worry i am not piling on more stuff beyond that of TestNG!


>> 
>>> It doesn't seem like it needs to be checked in (and is missing copyright).
>>> 
>> Ah, thanks, i will add the 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.
>>> 
>> But how much of an actual slog is it? (see my reply to you on hotspot-dev)
>> 
>> If i cannot persuade you and others in the runtime team (my powers of persuasion are failing and it is looking unlikely, but i am still trying :-) ), i will move them to the idk test area.
> 
> As I said in my last email, the test should be in the hotspot test repositories because it seems like compiler changes could break them and we'd want to run the tests with each putback.

It tests the native methods, and C1/C2 intrinsics if given the freedom to do so, thus it really exercises both runtime and compiler, but an argument can be made for locating in compiler.


>   See if the compiler group can tolerate an additional harness.
> 

“Wanted: one careful owner” :-)

Paul.