jdk10/hs integration status

[Daniel D. Daugherty]

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