Invalid ranges for options

[David Holmes]

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
>>>>>>>