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