jdk10/hs integration status

[Daniel D. Daugherty]

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
>>>>
>>>
>