Advice on how to use JMH for benchmarking an application that uses ExecutorService?

[Behrooz N]

Hi,

Thanks for your explanations and hints. Diagnosis of the issue revealed
that the blocking behavior was caused by using PriorityBlockingQueue for
ExecutorService.

Another question that has occurred to me since you've been active on this
domain. Is there any scientific literature that argues what types of
microbenchmarks are suitable for which types of applications?

And, thanks for the great tool you have built.

Cheers,
Behrooz


On Mon, Feb 3, 2014 at 9:44 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 02/04/2014 12:36 AM, Behrooz N wrote:
> > I have started to use JMH with @BenchmarkMode(SampleTime). The question
> > rose to me when at predictable runs of the benchmark, the runner seems to
> > get stuck at some iteration. I tried to use jstack to identity any
> possible
> > deadlock but it revealed nothing. This behavior was much more recurrent
> > when using Throughput mode.
>
> Are you shutting down the executor? The non-daemon threads will prevent
> JVM to exit, and so forked VM will never return, and the run will be
> stalled. Hence the alternative: daemon threads.
>
> It's hard to tell what is wrong otherwise. More logs and jstack traces
> needed to hypothesize what could be wrong.
>
> > So, I am asking for advice for the configurations on memory, fork
> > configuration, threads, iteration sync or any example document that have
> > hints on this.
>
> SampleTime is the best suitor for the job. There is no other strong
> requirements per se, but choose the options wisely :) The only other
> thing I can think of is modeling the think-time between requests, e.g.:
>
>
> http://hg.openjdk.java.net/code-tools/jmh/file/f2e982b7c51b/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_07_FixtureLevelInvocation.java
>
> -Aleksey.
>
>


-- 
-- Behrooz Nobakht