jdk10/hs integration status

[Daniel D. Daugherty]

Based on the Aurora job log for this testsuite run, it looks to
me like UTE is being used to execute JTREG which executes these
tests.

Dan


On 9/2/17 10:56 PM, Daniel D. Daugherty wrote:
> The test suite execution directory has a jtreg.sh script:
>
> 'time' ''/bin/bash'' 
> '/export/home/aginfra/CommonData/jtreg_dir/bin/jtreg' 
> '-testjdk:"/export/home/aginfra/CommonData/TEST_JAVA_HOME"' 
> '-dir:/export/home/aginfra/CommonData/j2se_jdk/jdk//test' 
> '-w:/export/home/aginfra/sandbox/results/workDir' 
> '-r:/export/home/aginfra/sandbox/results/report' '-retain:fail,error' 
> '-status:notRun,error,fail' '-ignore:quiet' '-a' '-javacoptions:' 
> '-javaoption:-Xmixed' '-javaoption:-server' 
> '-javaoption:-XX:MaxRAMPercentage=12.5' ''-k:!ignore'' '-timeout:16' 
> '-verbose:summary' 
> '-nativepath:/export/home/aginfra/sandbox/JTREG_NATIVEPATH_LIBRARY_PREPARED' 
> '-thd:/export/home/aginfra/CommonData/JTREG_EFH_HOME/jtregFailureHandler.jar' 
> '-th:jdk.test.failurehandler.jtreg.GatherProcessInfoTimeoutHandler' 
> '-od:/export/home/aginfra/CommonData/JTREG_EFH_HOME/jtregFailureHandler.jar' 
> '-o:jdk.test.failurehandler.jtreg.GatherDiagnosticInfoObserver' 
> '-J-Djava.library.path='/export/home/aginfra/CommonData/JTREG_EFH_HOME'' 
> '-othervm' '-conc:3' '-vmoptions:'-XX:MaxRAMFraction=6'' 
> '-exclude:/export/home/aginfra/sandbox/results/exclude1.jtx' 
> '-exclude:/export/home/aginfra/sandbox/results/exclude2.jtx' 'tools'
>
> so whatever Aurora/RBT used to setup this job added: -XX:MaxRAMFraction=6
>
> Dan
>
>
> On 9/2/17 10:52 PM, Daniel D. Daugherty wrote:
>> On 9/2/17 10:40 PM, David Holmes wrote:
>>> On 3/09/2017 12:49 AM, Daniel D. Daugherty wrote:
>>>> We're not completely out of the woods. These tests:
>>>>
>>>> tools/jar/modularJar/Basic.java
>>>> tools/jar/multiRelease/ApiValidatorTest.java
>>>> tools/jar/multiRelease/Basic.java
>>>> tools/launcher/InfoStreams.java
>>>>
>>>> still failed in the 2017-09-01 JDK10-hs nightly with:
>>>>
>>>> java.lang.AssertionError: Unknown value Java HotSpot(TM) 64-Bit 
>>>> Server VM warning: Option MaxRAMFraction was deprecated in version 
>>>> 10.0 and will likely be removed in a future release.
>>>
>>> Isn't that the nightly we're talking about Dan?
>>
>> No. The failures that were originally discussed were in
>> the 2017-08-31 JDK10-hs nightly and were mostly caused by
>> Calvin's rerun JPRT job.
>>
>> I found a couple of places in the current JDK10-hs repo where
>> MaxRAMFraction is still used, but none that explain the above
>> four test failures. My conclusion is that they are picking up
>> the MaxRAMFraction from whatever mechanism is being used to
>> launch those tests...
>>
>> These two kitchensink config files still use MaxRAMFraction:
>>
>> ./hotspot/test/closed/applications/kitchensink/kitchensink.default.properties:test.jvm.args=-XX:MaxRAMFraction=2 
>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false 
>> -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData 
>> -Xlog:gc*:gc.log -XX:+DisableExplicitGC -XX:+PrintFlagsFinal 
>> -XX:+StartAttachListener -XX:+UnlockCommercialFeatures 
>> -XX:NativeMemoryTracking=detail -XX:+ResourceManagement 
>> -XX:+FlightRecorder
>> ./hotspot/test/closed/applications/kitchensink/kitchensink.default.properties:original.jvm.args=-XX:MaxRAMFraction=8 
>> -Djava.net.preferIPv6Addresses=false
>>
>> Dan
>>
>>
>>> Those tests only fail if the closed repo has not got Bob's changes 
>>> that switch from MaxRAMFraction to MaxRAMPercentage.
>>>
>>> David
>>>
>>>> Dan
>>>>
>>>>
>>>> On 9/2/17 6:30 AM, jesper.wilhelmsson at oracle.com wrote:
>>>>>> On 2 Sep 2017, at 13:03, David Holmes <david.holmes at oracle.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Jesper,
>>>>>>
>>>>>> On 2/09/2017 8:15 PM, jesper.wilhelmsson at oracle.com wrote:
>>>>>>> Hi,
>>>>>>> After going through the results of our nightlies it seems we are 
>>>>>>> in fairly good shape for integration. There was one issue with a 
>>>>>>> typo in a recent fix that caused some failures, this issue was 
>>>>>>> resolved yesterday just after the nightly snapshot was taken.
>>>>>> The JPRT job that was used for the nightly testing was not valid. 
>>>>>> The repos were out of sync due to a re-run with an intervening 
>>>>>> integration job. The MaxRAMFraction failures in the tools tests 
>>>>>> below were caused by that.
>>>>> Sigh... I thought we didn't use rerun for integration jobs.
>>>>>
>>>>> Thanks for the heads-up David!  I'll start a new nightly now to 
>>>>> get a trustworthy result.
>>>>>
>>>>> /Jesper
>>>>>
>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> There is currently one issue that I didn't recognise and at the 
>>>>>>> moment it is marked as an integration blocker:
>>>>>>> JDK-8187124 <https://bugs.openjdk.java.net/browse/JDK-8187124>
>>>>>>> TestInterpreterMethodEntries.java: Unable to create shared 
>>>>>>> archive file <https://bugs.openjdk.java.net/browse/JDK-8187124>
>>>>>>> This could as well be a problem with the test execution in which 
>>>>>>> case it is not a blocker, but someone needs to look into the 
>>>>>>> details here.
>>>>>>> There are four test failures that looks slightly different:
>>>>>>> tools/jar/modularJar/Basic.java
>>>>>>> tools/jar/multiRelease/ApiValidatorTest.java
>>>>>>> tools/jar/multiRelease/Basic.java
>>>>>>> tools/launcher/InfoStreams.java
>>>>>>> These four tests fails because they get a warning on stderr:
>>>>>>> Option MaxRAMFraction was deprecated in version 10.0 and will 
>>>>>>> likely be removed in a future release.
>>>>>>> I do not consider this a blocker for integration, bug filed: 
>>>>>>> JDK-8187125 <https://bugs.openjdk.java.net/browse/JDK-8187125>
>>>>>>> JDK10/hs now has restricted write access. Basically it is locked 
>>>>>>> but in order to fix any urgent issues that might pop up over the 
>>>>>>> next couple of days these people have write access: Vladimir 
>>>>>>> Kozlov, Dan Daugherty, Stefan Karlsson, and myself.
>>>>>>> /Jesper
>>>>>
>>>>
>>
>