Invalid ranges for options

[Lindenmaier, Goetz]

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

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