RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12
Baesken, Matthias
matthias.baesken at sap.com
Tue Aug 27 13:49:18 UTC 2019
Hi Bob, that's the new change :
http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/
I do not set " opts.appendTestJavaOptions = false;" any more . Instead I set the Xmx . However doing so requires the setting AFTER the testJavaOpts.
> >>>> 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.
Regarding your concern :
> I would be concerned that the change in ordering would break other tests.
That might be possible .
In case we want to be safe, I suggest to add an additional method " appendJavaOpts "
opts.appendJavaOpts("-Xmx" + javaHeapSize);
to DockerRunOptions ; appendJavaOpts would append the options after the testJavaOpts (so Xmx can be overwritten ).
Best regards, Matthias
> -----Original Message-----
> From: Bob Vandette <bob.vandette at oracle.com>
> Sent: Dienstag, 27. August 2019 15:18
> 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
>
> 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