RFR 8199868: Support JNI critical functions in object pinning API

[Daniel D. Daugherty]

On 8/1/18 10:27 AM, Zhengyu Gu wrote:
>
>>
>> Just to close the loop on this adventure... Solaris SPARC is
>> included in the jdk-submit machine matrix. I was told it wasn't,
>> but Christian chased down Zhengyu's jdk-submit job and it did
>> pass Solaris SPARC builds and tests...
>>
>> The reason that it passed is the new test wasn't in the source
>> bundle:
>>
>> $ ls open/test/hotspot/jtreg/gc/epsilon/
>> TestAlwaysPretouch.java        TestLogTrace.java
>> TestByteArrays.java        TestManyThreads.java
>> TestDieDefault.java        TestMemoryMXBeans.java
>> TestDieWithHeapDump.java    TestMemoryPools.java
>> TestDieWithOnError.java        TestObjects.java
>> TestElasticTLAB.java        TestPrintHeapSteps.java
>> TestElasticTLABDecay.java    TestRefArrays.java
>> TestEpsilonEnabled.java        TestUpdateCountersSteps.java
>>
>> So these three files are not there:
>>
>> + test/hotspot/jtreg/gc/epsilon/CriticalNativeArgs.java
>> + test/hotspot/jtreg/gc/epsilon/CriticalNativeStress.java
>> + test/hotspot/jtreg/gc/epsilon/libCriticalNative.c
>>
>> which is why the jdk-submit job passed, but the CI job for
>> the actual push failed.
>>
>> It should all be fixed as of last night. I just wanted to
>> close the loop on this mystery...
>
> Hummm .. I am really confused here.
>
> I did submit twice.

Hmmm... When I search Mach5 with 'id:*JDK-8199868*', I see only one
recent Mach5 job:

mach5-one-zgu-JDK-8199868-20180731-1538-33107

The others are back in May and April...


> The first submit did miss tests:
>
> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002532.html 
>
>
> but, it came back as unstable.

This email lists the changeset ID as: 630c90079d38

And Mach5 shows the verbose changeset id for
mach5-one-zgu-JDK-8199868-20180731-1538-33107 as:

hg -R open update -c -r 630c90079d38795aa44a506320df1b950392d26c

so we have a match. So the Mach5 job that Christian found (and that
I found just now) matches the one without the test.


> Then I did the second submit, which included tests:
>
> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html 
>
>
> and got all clear results.

This email lists the changeset ID as: 2cd8bbccbd2d

I did another Mach5 search using 'userEmail:zgu at redhat.com*' and
it shows only one job for you on 07.31:

mach5-one-zgu-JDK-8199868-20180731-1538-33107

and one job for you running right now (for 8208635).

In other words, I can't find any trace that your second jdk-submit
job for 8199868 actually ran in Mach5.


> so, you mean that the all clear results were from the first submit?

That's what it looks like to me.


> did it get reran?

I don't know. Looking at your first job for 8199868 in Mach5,
I don't see any failures. All 75 tasks passed and no test
failures are reported.

I think it's possible that the "unstable" indicator you got
was from your second job? I really don't know for sure...


> but I did not receive any new results after that ...
>
> Is it possible to generate link in test results, that points to the 
> submit job?

I don't think so because that would be an Oracle internal link.
However, I'm not all that familiar with the jdk-submit system.
In fact this is my first time poking around it...

Dan


>
> -Zhengyu
>
>>
>> Dan
>>
>>
>>
>>>
>>> Dan
>>>
>>>
>>>>>
>>>>> I have a fix reviewed and I'm waiting for the mach5 tier1
>>>>> builds to finish...
>>>>
>>>> Thank you, Dan.
>>>>
>>>> -Zhengyu
>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html 
>>>>>>
>>>>>>
>>>>>> And results I got:
>>>>>>
>>>>>> Build Details: 2018-07-31-1535425.zgu.source
>>>>>> 0 Failed Tests
>>>>>> Mach5 Tasks Results Summary
>>>>>>
>>>>>>     PASSED: 75
>>>>>>     FAILED: 0
>>>>>>     KILLED: 0
>>>>>>     NA: 0
>>>>>>     UNABLE_TO_RUN: 0
>>>>>>     EXECUTED_WITH_FAILURE: 0
>>>>>>
>>>>>> I will fix this right now.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 7/31/18 10:37 AM, Andrew Dinn wrote:
>>>>>>>> Hi Zhengyu,
>>>>>>>>
>>>>>>>> On 31/07/18 14:25, Zhengyu Gu wrote:
>>>>>>>>> I added comments as you suggested.
>>>>>>>>>
>>>>>>>>> Updated webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~zgu/8199868/webrev.04/
>>>>>>>> Ok, thanks.
>>>>>>>>
>>>>>>>> The above patch is reviewed modulo two misspellings of 
>>>>>>>> 'critical' as
>>>>>>>> 'ciritical' in CriticalNativeStress.java.
>>>>>>>>
>>>>>>>> No need for another webrev.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrew Dinn
>>>>>>>> -----------
>>>>>>>> Senior Principal Software Engineer
>>>>>>>> Red Hat UK Ltd
>>>>>>>> Registered in England and Wales under Company Registration No. 
>>>>>>>> 03798903
>>>>>>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric 
>>>>>>>> Shander
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>