Removing intrinsic of Thread.isInterrupted()

[Karen Kinnear]

Performance team folks -

I think it would be very helpful to identify any "real" benchmarks, rather than
a small hand-rolled micro-benchmark.

Compiler folks - 

Does anyone have the history of why this instrinsic was added? And what
benchmark(s) that was for?

I think it would help to get current data on those benchmarks or more recent
versions of them please.

thanks,
Karen

On Feb 25, 2014, at 1:05 PM, Aleksey Shipilev wrote:

> Hi Yumin,
> 
> On 02/25/2014 09:25 PM, Yumin Qi wrote:
>>  Thanks for the info, I modified as
> 
> Ok, if you still wish to go for hand-rolled benchmarks:
> 
>>        final int  NUM = 20000;
>>        boolean interrupts[] = new boolean[NUM];
>>        start = System.currentTimeMillis();
>>        for (int j = 0; j < 100; j++) {
>>            for (int i = 0; i < NUM; i++) {
>>                interrupts[i] = t.isInterrupted();
>>            }
>>        }
>>        finish = System.currentTimeMillis();
>>        osum = finish - start;
>>        System.out.println(NUM + " calls cost: " + osum  + " ms");
> 
> So, this benchmark still suffers from:
> * The absence of warmup
> * Dead-code elimination of interrupts[] accesses, and the elimination
> of t.isInterrupted as the result.
> * System.currentTimeMillis() (high) granularity
> * Loop unrolling for both "i" and "j" loops, further affected by the
> presence of inlined code for isInterrupted, or native call stub
> * Possible hoisting of t.isInterrupted() from the loop (native methods
> should be immune, and I remember there should be the barrier in the
> intrinsic to prevent that)
> 
>> The result showed no difference (even a little better without intrinsic).
> 
> ...and that begs the question, right? Why does it happen? Why the
> performance is similar for seemingly different code paths? Is intrinsic
> not working whatsoever? Is the experiment correct? Do we actually
> measure it right, etc?
> 
>> I think I can remove it from hotspot.
> 
> I don't think we can, until we understand the performance implications
> through and through.
> 
> Thanks,
> -Aleksey.