Question about exception I am seeing after upgrading to jmh 1.15

[Zoltan Farkas]

Thank you, Once I disabled the FJP, everything started working again.

Also FJP’s LIFO scheduling makes it more likely that a thread will be idle and will get retired… 

From what I understand, I believe JMH should probably take control of the thread lifecycle and not rely on executors.

In any case I should have probably been using the JMH defaults… 

thank you for your help...

—Z

> On Oct 7, 2016, at 6:24 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Hi Zoltan,
> 
> On 10/07/2016 03:04 AM, Zoltan Farkas wrote:
>> java.lang.Exception: java.lang.IllegalStateException: Cannot get another thread params
>> 	at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:489)
>> 	at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:448)
>> 	at java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1424)
>> 	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
>> 	at java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:401)
>> 	at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:734)
>> 	at java.util.concurrent.ForkJoinTask$AdaptedCallable.run(ForkJoinTask.java:1434)
>> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> 	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
>> 	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
>> 	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
>> 	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
>> 	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
>> Caused by: java.lang.IllegalStateException: Cannot get another thread params
>> 	at org.openjdk.jmh.runner.BenchmarkHandler$1.initialValue(BenchmarkHandler.java:85)
>> 	at org.openjdk.jmh.runner.BenchmarkHandler$1.initialValue(BenchmarkHandler.java:78)
>> 	at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
>> 	at java.lang.ThreadLocal.get(ThreadLocal.java:170)
>> 	at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:463)
>> 	... 13 more
> 
> Mhm.
> 
> That looks like there are more worker threads than harness has allocated
> the thread-local data for. I think FJP is a factor here: it probably
> instantiates another set of threads on the next iteration, and fails
> when those threads are trying to get new thread data.
> 
> AFAIU, FJP would trim the workers (and then instantiate more) when this
> threshold is reached:
> 
>    /**
>     * Initial timeout value (in milliseconds) for the thread
>     * triggering quiescence to park waiting for new work. On timeout,
>     * the thread will instead try to shrink the number of workers.
>     * The value should be large enough to avoid overly aggressive
>     * shrinkage during most transient stalls (long GCs etc).
>     */
>    private static final long IDLE_TIMEOUT_MS = 2000L; // 2sec
> 
> This, BTW, tells me that using non-standard executors really mess up the
> @State(Thread) invariants: you could execute the @Setup for those state
> objects several times, as your threads come and go. Which is what
> previous JMH version used to do.
> 
> I think the long-term strategy for us is to consider "seamless
> iterations", where we don't release the worker thread between
> iterations, and thus do not set ourselves up for this failure.
> Short-term, you can keep using previous JMH version if you can accept
> @State(Thread) bug.
> 
> Thanks,
> -Aleksey