RFR (XXS) 8228907: Some gc argument checking tests fail after JDK-8228855

[David Holmes]

On 1/08/2019 7:56 am, Kim Barrett wrote:
>> On Jul 31, 2019, at 5:41 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 1/08/2019 6:01 am, coleen.phillimore at oracle.com wrote:
>>> Summary: Use new SurvivorAlignmentInBytes range in tests, remove test cases that verify unnecessarily large values.
>>
>> As long as the GC team agree they are unnecessarily large the changes seem fine.
> 
> If we’re not going to allow values that large (per JDK-8228855), then trying to test them here is pointless.

Of course, but my question was really whether the way to fix the current 
problem is by limiting the test to the max value set by JDK-8228855, or 
whether JDK-8228855 was wrong to set such a low maximum and that it 
should be changed. The fact you were testing larger values suggests 
there was some expectation of using larger values, but Coleen already 
addressed this in her reply.

> We do end up with some intertwined dependencies though, and I’m not seeing a good way to deal with that.
> The range that makes sense to test here is limited by the valid range for SurvivorAlignmentInBytes.
> Maybe have the test take a special “MAX_VALUE” token and ask the VM for the max value?  Do we
> have that capability at all right now (perhaps via WhiteBox)?  I don’t recall seeing anything like that,
> but might be forgetting.

I don't know of anything. I think the explicit SurvivorAlignmentInBytes 
test has to be aware of the constraints that apply to the flags it is 
using. I remain unclear how the more general TestOptionsWithRanges test 
is supposed to work, but that's being discussed in the JDK-8228855 
review thread.

> Even if we want to do something like that, I think it should be done as a followup.  For now, getting this
> failure out of testing seems more urgent than improving the test.

Of course.

David

>>
>> Thanks,
>> David
>>
>>> Tested locally with:
>>> make test TEST=gc/arguments
>>> Will wait for hs-tier1-3 to finish before pushing after reviewed.
>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8228907.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8228907
>>> Thanks,
>>> Coleen
> 
>