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

Baesken, Matthias matthias.baesken at sap.com
Tue Aug 27 13:12:19 UTC 2019 

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