Invalid ranges for options

Fri Jun 10 01:02:49 UTC 2016

On 9/06/2016 11:16 PM, Dmitry Dmitriev wrote:
> 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)..

Note we want to test only with _disabled_ SafepointTimeout - otherwise 
we will hit the timeout for the min test and report a failure.

David
-----

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