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

[Mikhailo Seledtsov]

I agree with Bob. It seems this is exactly what we wish in this case: 
filter out/eliminate some options that interfere with the test, while 
retaining other options and passing them to the JVM running inside a 
container.


Thank you,
Misha

On 8/27/19, 8:42 AM, Bob Vandette wrote:
> 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