RFR (T) 8228855: Test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails after JDK-8227123

[David Holmes]

On 31/07/2019 11:39 pm, coleen.phillimore at oracle.com wrote:
> On 7/31/19 9:25 AM, coleen.phillimore at oracle.com wrote:
>> On 7/31/19 9:12 AM, David Holmes wrote:
>>> I haven't seen Coleen's original mail turn up yet, so I'll respond here.
> 
> I haven't gotten the email yet either.
>>>
>>> Shouldn't the range be handled by the constraint function:
>>
>> It is not handled that way in ObjAlignmentInBytes.
> 
> What I meant is that ObjectAlignmentInBytes has the constraint function 
> AND the range.  SurvivorAlignmentInBytes should be the same.  The 
> constraint function tests that it's > ObjectAlignmentInBytes.
> 
>   158   lp64_product(intx, ObjectAlignmentInBytes, 
> 8,                             \
>   159           "Default object alignment in bytes, 8 is 
> minimum")                \
>   160           range(8, 
> 256)                                                     \
>   161           
> constraint(ObjectAlignmentInBytesConstraintFunc,AtParse)          \

Okay, so specifying the range is reasonable and I guess specifying the 
same range as ObjectAlignmentInBytes is also reasonable.

Note however that the default value for SurvivorAlignmentInBytes is 0 
which is outside of the specified range, so I'm not sure if that makes 
sense. AFAICS the constraint function only applies if the flag is 
explicitly set so that default value is ignored. I don't know if that is 
the case for the range check ??

But given the dependency between these two flags the test won't be able 
to adjust SurvivorAlignmentInBytes independently of ObjectAlignmentInBytes.

David
-----

> 
> Coleen
>>
>> Coleen
>>>
>>>  SurvivorAlignmentInBytesConstraintFunc
>>>
>>> ?
>>>
>>> David (signing off for the night)
>>>
>>> On 31/07/2019 11:04 pm, Aleksey Shipilev wrote:
>>>> On 7/31/19 2:56 PM, coleen.phillimore at oracle.com wrote:
>>>>> open webrev at 
>>>>> http://cr.openjdk.java.net/~coleenp/2019/8228855.01/webrev
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8228855
>>>>
>>>> Looks good and trivial.
>>>>
>>
>