Invalid ranges for options

Thu Jun 9 13:16:16 UTC 2016

Hello Goetz,

Yes, it seems that dependency for SafepointTimeoutDelay should be added 
to the test(i.e. test SafepointTimeoutDelay with enabled 
SafepointTimeout). This can be done in addNameDependency 
method(JVMOptionsUtils.java)..

Also, if some value is valid, but problematic(consume a lot of system 
resources or other things), it can be removed from the test. It can be 
removed completely(excludeTestRange()) or exclude only min/max 
values(excludeTestMinRange or excludeTestMaxRange) in the 
TestOptionsWithRanges.java.

Thanks,
Dmitry

On 09.06.2016 11:19, Lindenmaier, Goetz wrote:
> Ok, then just keep it as is.
>
> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 9. Juni 2016 09:52
>> 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 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
>>>>>>>>>>>