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

[Baesken, Matthias]

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