Removing intrinsic of Thread.isInterrupted()

[Aleksey Shipilev]

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.