[External] : Re: InterruptedException in InfraControl.preTearDown so far only on ARM

[eric.caspole at oracle.com]

Hi Aleksey,
I tried this patch about 30 times, it always worked and reported the 
score. There is the funny quirk that sometimes there are hundreds (and 
hundreds) of
(*interrupt*) messages at the end of the iteration before the score is 
printed like below.
Thanks for this patch!
Eric


(*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) 
(*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) 
(*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) 
(*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) 
(*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) 
(*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) 
(*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) 
(*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) (*interrupt*) 
(*interrupt*) (*interrupt*) 643.490 s/op


On 7/30/21 3:34 AM, Aleksey Shipilev wrote:
> 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://urldefense.com/v3/__https://github.com/openjdk/jmh/pull/45__;!!ACWV5N9M2RV99hQ!fRuf98FOhdNmafZ1ctXWXMZINwkiNrmh9mE6F4zMF1zRxS4cVmrg23tZSgiIT7rSHw$ 
>