Invalid ranges for options

[Lindenmaier, Goetz]

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