Removing intrinsic of Thread.isInterrupted()

[Christian Thalinger]

On Feb 25, 2014, at 10:05 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> 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?

No we don’t.  I was having a hard time to believe that a JNI call is as faster (or even faster) then the intrinsic so I looked into the test case and the intrinsic.  Here is the condition when the intrinsic goes fast-path:

  // Add a fast path to t.isInterrupted(clear_int):
  //   (t == Thread.current() && (!TLS._osthread._interrupted || !clear_int))
  //   ? TLS._osthread._interrupted : /*slow path:*/ t.isInterrupted(clear_int)

The first condition is not true in the test case so we always go slow-path.

> 
>> 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.