Invalid ranges for options

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Jun 9 07:40:58 UTC 2016


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.

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


More information about the hotspot-runtime-dev mailing list