RFR (S) 7901022: JMH runners should provide explicit timeout setting

[Aleksey Shipilev]

Okay, printing the warning:
 http://cr.openjdk.java.net/~shade/7901022/webrev.02/

The printing itself here:

http://cr.openjdk.java.net/~shade/7901022/webrev.02/jmh-core/src/main/java/org/openjdk/jmh/runner/format/TextReportFormat.java.sdiff.html

-Aleksey.

On 09/10/2014 07:25 PM, Sergey Kuksenko wrote:
> JMH may print warning and continue executions as is.
> 
> On 09/10/2014 07:22 PM, Sergey Kuksenko wrote:
>> But  what to do when someone want to measure something for 12 minutes
>> iteration and he/she didn't read demos/manuals correctly and/or forget
>> about timeout?
>>
>> On 09/10/2014 07:09 PM, Aleksey Shipilev wrote:
>>> Thanks!
>>>
>>> Current code does not treat the case (runtime > timeout) in any specific
>>> manner. You will get the interrupt right in the middle of the run. I can
>>> think up the case when you actually want that to test the interrupt
>>> mechanics, so current code seems to be what we want it to be. Thoughts?
>>>
>>> -Aleksey.
>>>
>>> On 09/10/2014 06:50 PM, Sergey Kuksenko wrote:
>>>> Checked with one eye (you need yet another eye :))
>>>> Looks fine, except: What are you going to do if iteration time is
>>>> larger
>>>> than timeout?
>>>>
>>>>
>>>> On 09/10/2014 06:30 PM, Aleksey Shipilev wrote:
>>>>> Hi,
>>>>>
>>>>> I need a second pair of eyes to look through the patch:
>>>>>     http://cr.openjdk.java.net/~shade/7901022/webrev.01/
>>>>>
>>>>> Please take a look. It removes the current "timeout" scheme that
>>>>> guesses
>>>>> the timeout based on -r/measurementTime settings, and instead does the
>>>>> explicit -to/timeout setting to control how much we wait. It also does
>>>>> the waiting properly in multi-threaded workloads: do not wait for an
>>>>> entire time, but only for the remaining part of it.
>>>>>
>>>>> Context:
>>>>>     https://bugs.openjdk.java.net/browse/CODETOOLS-7901022
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/jmh-dev/2014-September/001369.html
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> -Aleksey.
>>>>>
>>>>
>>>
>>>
>>
>