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

[Sergey Kuksenko]

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

-- 
Best regards,
Sergey Kuksenko