RFR (S) 7901022: JMH runners should provide explicit timeout setting
Sergey Kuksenko
sergey.kuksenko at oracle.com
Wed Sep 10 15:22:01 UTC 2014
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
More information about the jmh-dev
mailing list