RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12

Bob Vandette bob.vandette at oracle.com
Tue Aug 27 13:18:04 UTC 2019 

I would be concerned that the change in ordering would break other tests.

Your experiment shows that appendTestJavaOptions is true!

Aren't you setting this to false??

Bob.


> On Aug 27, 2019, at 9:12 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi Bob,  I looked  a bit more into  it.   With  this  small additional change  :
> 
> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java
> 
>    public static List<String> buildJavaCommand(DockerRunOptions opts) throws Exception {
>    ......
>        // ********* move AFTER  test java options    **********
>        //cmd.addAll(opts.javaOpts);
>        if (opts.appendTestJavaOptions) {
>            Collections.addAll(cmd, Utils.getTestJavaOpts());
>        }
>        cmd.addAll(opts.javaOpts);
> 
>        cmd.add(opts.classToRun);
>        cmd.addAll(opts.classParams);
> 
>        return cmd;
>    }
> 
> 
> It works.    Obviously  the  Utils.getTestJavaOpts   would overwrite  the Xmx  setting from  javaOpts.
> Do you think it is fine  to   change the order  of  javaOpts and testJavaOpts ?
> 
> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: Bob Vandette <bob.vandette at oracle.com>
>> Sent: Dienstag, 27. August 2019 14:44
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Severin Gehwolf <sgehwolf at redhat.com>; Langer, Christoph
>> <christoph.langer at sap.com>; hotspot-dev at openjdk.java.net; Zeller, Arno
>> <arno.zeller at sap.com>
>> Subject: Re: RFR [XS] : 8229182:
>> runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12
>> 
>> Can you send out the updated webrev?
>> 
>> Are you sure you retained this change?
>> 
>>   opts.appendTestJavaOptions = false;
>> 
>> We’ll need to figure out why this isn’t inhibiting the jtreg options.
>> 
>> Bob.;
>> 
>> 
>> 
>>> On Aug 27, 2019, at 8:35 AM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> 
>>> Hi  Bob,  I tried your suggestion  .
>>> 
>>> It leads to
>>> 
>>> java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from
>> stdout/stderr
>>> 
>>> 	at
>> jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187)
>>> 	at
>> TestMemoryAwareness.testOOM(TestMemoryAwareness.java:120)
>>> 	at TestMemoryAwareness.main(TestMemoryAwareness.java:63)
>>> 	at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>>> 	at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet
>> hodAccessorImpl.java:62)
>>> 	at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega
>> tingMethodAccessorImpl.java:43)
>>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>>> 	at
>> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(
>> MainActionHelper.java:298)
>>> 	at java.base/java.lang.Thread.run(Thread.java:830)
>>> 
>>> JavaTest Message: Test threw exception: java.lang.RuntimeException
>>> JavaTest Message: shutting down test
>>> 
>>> result: Failed. Execution failed: `main' threw exception:
>> java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from
>> stdout/stderr
>>> 
>>> 
>>> In the docker call we have now both
>>> 
>>> -Xmx133m   and   -Xmx768m
>>> 
>>> See :
>>> 
>>> docker run --tty=true --rm --volume /net/usr.work/d040975/mytmp/jtreg-
>> workdir/classes/containers/docker/TestMemoryAwareness.d:/test-classes/
>> --memory 256m --memory-swappiness 0 --memory-swap 256m jdk-
>> internal:test-memory /jdk/bin/java -Xlog:os+container=trace -cp /test-
>> classes/ -Xmx133m -Xmx768m -Djava.awt.headless=true AttemptOOM 266
>>> 
>>> 
>>> Best regards, Matthias
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Bob Vandette <bob.vandette at oracle.com>
>>>> Sent: Freitag, 16. August 2019 14:36
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>> Cc: Severin Gehwolf <sgehwolf at redhat.com>; Langer, Christoph
>>>> <christoph.langer at sap.com>; hotspot-dev at openjdk.java.net; Zeller,
>> Arno
>>>> <arno.zeller at sap.com>
>>>> Subject: Re: RFR [XS] : 8229182:
>>>> runtime/containers/docker/TestMemoryAwareness.java test fails on
>> SLES12
>>>> 
>>>> Instead of adding this: opts.appendTestJavaOptions = false;
>>>> 
>>>> 
>>>> Try adding these lines:
>>>> 
>>>> String javaHeapSize = new String(sizeToAllocInMb/2) + “m”;
>>>> 
>>>> opts.addJavaOpts("-Xmx" + javaHeapSize);
>>>> 
>>>> This will set the max Java Heap to 1/2 of the size that we will attempt to
>>>> allocate.
>>>> This should reliably cause an OOM exception.
>>>> 
>>>> Bob.
>>>> 
>>>> 
>>>>> On Aug 16, 2019, at 4:14 AM, Baesken, Matthias
>>>> <matthias.baesken at sap.com> wrote:
>>>>> 
>>>>>> Can we not set -Xmx explicitly after any test options have been
>>>>>> appended so that it takes precedence?
>>>>> 
>>>>> Hi Bob,   do you have a good estimate for an Xmx to set ?
>>>>> 
>>>>>> It seems fragile to disable
>>>>>> appinding all test options altogether. Clearly, this test is
>>>>>> susceptible to passed -Xmx options.
>>>>> 
>>>>> We  have here a java - execution  taking place in the docker container,
>> not
>>>> the test machine itself .
>>>>> I am not sure , are the "regular"   test options so good for this special
>>>> execution ? Some maybe are , some aren’t ...
>>>>> 
>>>>> E.g.  we ended up  with
>>>>> 
>>>>> -Xmx768m -Djava.awt.headless=true
>>>>> 
>>>>> and more strange settings  in the  "docker run"   call because of this   ...
>>>>> 
>>>>> Best regards, Matthias
>>>>> 
>>>>> 
>>>>> 
>>>>>> Hi Matthias,
>>>>>> 
>>>>>> On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote:
>>>>>>>> Unfortunately  we do not see the expected
>>>>>> "java.lang.OutOfMemoryError"
>>>>>>>> in the nightly test runs .
>>>>>>>> 
>>>>>>>> When I execute  the  jtreg test locally  on the same (!)  ppc64le
>>>> machine ,
>>>>>>>> under the same user  but not from  the test framework we use
>> nightly
>>>>>>>> the  "java.lang.OutOfMemoryError"      shows up.
>>>>>>> 
>>>>>>> Hello, after looking a bit more into it,   we observed   that  the  nightly
>>>> runs
>>>>>> set a higher -Xmx  = 768m  value  that gets inherited  into the
>>>>>> DockerRunOptions
>>>>>>> And made the  central  test  fail .
>>>>>>> So I had to remove this  :
>>>>>>> 
>>>>>>> 105         // make sure we avoid Xmx settings from the jtreg vmoptions
>>>>>>> 106         opts.appendTestJavaOptions = false;
>>>>>> 
>>>>>> Can we not set -Xmx explicitly after any test options have been
>>>>>> appended so that it takes precedence? It seems fragile to disable
>>>>>> appinding all test options altogether. Clearly, this test is
>>>>>> susceptible to passed -Xmx options.
>>>>>> 
>>>>>> Failing that, could we just omit the -Xmx option?
>>>>>> 
>>>>>> Thanks,
>>>>>> Severin
>>>>>> 
>>>>>>> New webrev :
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/
>>>>>>> 
>>>>>>> Best regards, Matthias
>>>>>>> 
>>>>>>> 
>>>>>>>> Hi Christoph,
>>>>>>>> 
>>>>>>>>> Hi Matthias,
>>>>>>>>> 
>>>>>>>>> looks good to me in general.
>>>>>>>>> 
>>>>>>>>> However, I'm not convinced that line 114
>>>>>>>>> ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a
>>>>>> test
>>>>>>>>> error in case the child process was killed by the container, e.g.
>> exited
>>>>>> with
>>>>>>>>> exit code 137. We should at least run this patch for several days in
>> our
>>>>>>>> system
>>>>>>>>> to see if it catches all variations of the problem.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Unfortunately  we do not see the expected
>>>>>> "java.lang.OutOfMemoryError"
>>>>>>>> in the nightly test runs .
>>>>>>>> 
>>>>>>>> When I execute  the  jtreg test locally  on the same (!)  ppc64le
>>>> machine ,
>>>>>>>> under the same user  but not from  the test framework we use
>> nightly
>>>>>>>> the  "java.lang.OutOfMemoryError"      shows up.
>>>>>>>> 
>>>>>>>> Best regards, Matthias
>>>>>>>> 
>>>>>>>> 
>>>>> 
>>> 
>

More information about the hotspot-dev mailing list