Question about exception I am seeing after upgrading to jmh 1.15

[Aleksey Shipilev]

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