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

[Bob Vandette]

This is an isolated problem and I don’t like the idea of adding a new option just for this case.

What if we parse the options and eliminated the general -Xmx option if one was specified
by the test?  After all, this is the intention of adding a test specific heap limit.

Bob.



> On Aug 27, 2019, at 10:33 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> 
> On Tue, 2019-08-27 at 14:20 +0000, Baesken, Matthias wrote:
>> Hello  ,   my suggestions was " appendJavaOpts "   :
>> 
> 
> OK, got it now. Looking at the webrev this wasn't clear as it didn't do
> that.
> 
>>     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 ).
>> 
>> But if  overrideJavaOpts    is preferred  that fine with me too ...
> 
> I'd prefer a more telling name than "append". I'd ask myself when
> trying to use it: Does it append to regular java options? How is it
> different from addJavaOpts()? You get the idea. I'd prefer
> overrideJavaOpts for that reason.
> 
> Perhaps addOverrideOpts()? Either way, the javadoc should make it clear
> what adding options there means.
> 
> Thanks,
> Severin
> 
>> Best regards, Matthias
>> 
>> 
>>> On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote:
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/
>>> 
>>> OK, so, in summary, the constraints are as follows:
>>> 
>>> * We don't want to turn of appending global test java options as
>>> these
>>>   could possibly contain local options to a specific test
>>> environment.
>>>   It would be a surprise if docker tests wouldn't have them.
>>> * Just setting Java options is not enough as the intention is to
>>> set
>>>   them for the Docker test, but could potentially be overridden by
>>>   global test options (this issue).
>>> 
>>> Given we'd like to keep that general design, maybe it would make
>>> sense
>>> to create a 3'rd, separate set of flags, neither java options nor
>>> test
>>> options would manage to override. Call it "overrideJavaOpts" or
>>> some
>>> such. At least that would make it clear that these options if set
>>> have
>>> the final say.
>>> 
>>> Thoughts?
>>> 
>>> Thanks,
>>> Severin
>