Invalid ranges for options

[David Holmes]

On 9/06/2016 5:40 PM, Lindenmaier, Goetz wrote:
> I think you can as well do
>  allOptionsAsMap.remove("SafepointTimeoutDelay");
> because it's completely pointless to test the range of a flag
> that is not used at all, which is the case if SafepointTimeout is off.

The point of the test is not (necessarily) to check that the VM "works" 
with all values in the range, but that the value specified is within 
range. There are lots of legal but problematic values for options.

David

> Best regards,
>   Goetz.
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 9. Juni 2016 09:16
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: Invalid ranges for options
>>
>> On 9/06/2016 4:56 PM, Lindenmaier, Goetz wrote:
>>>>>> The range tests are primarily for legality not practicality.
>>>>> The test fails if -XX:+SafepointTimeout is set per default.  So the test is
>>>> wrong.
>>>>
>>>> You mean if you change the default of SafepointTimeout to be true?
>>> Yes.
>>>> Yes that would be unexpected in the test as it "knows" it is off normally. I
>>>> take it you are suggesting that the test explicitly disables
>>>> SafepointTimeout? That seems reasonable.
>>> That would be one solution.  Alternatively it could accept the safepoint
>>> timeout as legal result.
>>
>> That would be rather tricky I think, given the generic nature of the
>> range testing framework.
>>
>> But we should be able to add an entry to
>> JVMOptionsUtil.addNameDependency
>>
>> David
>>
>>> Best regards,
>>>   Goetz.
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> But no matter, I just wanted to share my findings, and if you think it's ok
>>>>> just keep it as is.
>>>>>
>>>>> Best regards,
>>>>>   Goetz
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Donnerstag, 9. Juni 2016 01:44
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>> runtime-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: Invalid ranges for options
>>>>>>
>>>>>> On 9/06/2016 12:02 AM, Lindenmaier, Goetz wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> I agree there is no obvious lower bound for this. We use this with
>>>>>>> rather big values, though (5 min, several hours) so that a lower bound
>>>>>>> of 100ms would be far from limiting.  And simple test shows that even
>>>>>>> 10ms helps.
>>>>>>>
>>>>>>> If the lower bound is a value that will not work for sure, it makes no
>>>>>>> sense to have it.  Also, it makes no sense to test the bounds without
>>>>>> activating
>>>>>>> the freature as TestOptionsWithRanges does.
>>>>>>> So I would remove both, the test and the bounds in this case.
>>>>>>
>>>>>> I think I'm misunderstanding the problem. What exactly are you
>> proposing
>>>>>> should be changed? The range checking of SafepointTimeoutDelay is
>>>>>> independent of the operation of the safepoint timeout facility. And if
>>>>>> you turn it on a delay of zero does exactly what I would expect. The
>>>>>> range tests are primarily for legality not practicality.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>> Best regards,
>>>>>>>   Goetz.
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Mittwoch, 8. Juni 2016 14:42
>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>>>> runtime-
>>>>>>>> dev at openjdk.java.net
>>>>>>>> Subject: Re: Invalid ranges for options
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> On 8/06/2016 8:27 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> As SAP JVM is has some different default settings,
>>>>>>>> TestOptionsWithRanges.java has
>>>>>>>>> detected two problematic ranges:
>>>>>>>>>   java -XX:MaxJNILocalCapacity=1 -
>>>>>>>> Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044
>>>>>>>>>   java -XX:+SafepointTimeout -XX:SafepointTimeoutDelay=0
>>>>>>>>
>>>>>>>> I don't see any problem with SafepointTimeoutDelay. If you set it to
>>>>>>>> zero there is no delay and it times out immediately. It may not be
>>>>>>>> useful, but then neither is a value of 1, 2, 3 ...
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> I think the ranges of MaxJNILocalCapacity and
>> SafepointTimeoutDelay
>>>>>>>> should be fixed.
>>>>>>>>> Should I open a bug for this?
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>   Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> bin/java  -XX:+SafepointTimeout -XX:SafepointTimeoutDelay=0
>>>>>>>>> # SafepointSynchronize::begin: Timeout detected:
>>>>>>>>> # SafepointSynchronize::begin: Timed out while waiting for threads
>> to
>>>>>> stop.
>>>>>>>>> # SafepointSynchronize::begin: Threads which did not reach the
>>>>>> safepoint:
>>>>>>>>> # "C1 CompilerThread14" #20 daemon prio=9 os_prio=0
>>>>>>>> tid=0x00007efe7c01f800 nid=0x8784 runnable [0x0000000000000000]
>>>>>>>>>    java.lang.Thread.State: RUNNABLE
>>>>>>>>>    JavaThread state: _thread_in_native
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> bin/java -XX:MaxJNILocalCapacity=1 -
>>>>>>>> Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044
>>>>>>>>> JDWP exit error AGENT_ERROR_OUT_OF_MEMORY(188):
>>>>>> PushLocalFrame:
>>>>>>>> Unable to push JNI frame [util.c:1559]
>>>>>>>>> FATAL ERROR in native method: JDWP PushLocalFrame: Unable to
>>>> push
>>>>>> JNI
>>>>>>>> frame, jvmtiError=AGENT_ERROR_OUT_OF_MEMORY(188)
>>>>>>>>> Current thread is 34829
>>>>>>>>> Dumping core ...
>>>>>>>>> Abort
>>>>>>>>>