InterruptedException in InfraControl.preTearDown so far only on ARM
Aleksey Shipilev
shade at redhat.com
Fri Jul 30 07:34:48 UTC 2021
Hi Eric,
On 7/30/21 12:01 AM, eric.caspole at oracle.com wrote:
> try {
> while (control.warmdownShouldWait) {
> blackhole.consume(l_getclient0_G.get());
> res.allOps++;
> }
> control.preTearDown();
> } catch (InterruptedException ie) {
> control.preTearDownForce();
> }
So this loop it trying to catch the InterruptedException from the benchmark call itself in the
warm-down loop. That IE happens when harness starts interrupting stuff after a timeout (-to). But
the trouble is, the interrupt might end up in preTearDown (await). This code is accidentally immune
to this trouble, as it would slide to preTearDownForce -- but it would still count down the latch twice.
> But the single shot wrapper has no try/catch there:
>
> int batchSize = iterationParams.getBatchSize();
>
> report_ss_jmhStub(control, res, benchmarkParams, iterationParams, threadParams, blackhole, notifyControl, startRndMask, batchSize, l_reporterbench0_0);
>
> control.preTearDown();
>
> if (control.isLastIteration()) {
>
> f_reporterbench0_0 = null;
>
> }
This code, however, was written knowing there is no warm-down loop, so that InterruptedException was
"not possible". We now know it suffers from the same problem, but there is no accidental recovery.
This whole thing is guaranteed to fail if @Benchmark does not check interrupt status at all. Then
the first thing that would check the interrupt status and throw IE would be the
control.preTearDown(). I suspect that is what happens on ARM: the method runs for too long, so JMH
starts to deliver interrupts, but method does not react and eventually exits on its own accord, at
which point JMH infra catches IE and fails.
I think this should fix it (as it fixes the regression test from the scenario above), please try:
https://github.com/openjdk/jmh/pull/45
--
Thanks,
-Aleksey
More information about the jmh-dev
mailing list