Removing intrinsic of Thread.isInterrupted()

[Yumin Qi]

Thanks! Yes, it will not go fast path. If change

t.isInterrupted() to
Thread.currentThread().isInterrupted()   (this has nothing to do with t 
then)

The result is:  57 ms vs 14 ms for 20000 * 100 times call.

Is that really important to other cost way above this level?

Thanks
Yumin

On 2/25/2014 10:26 AM, Christian Thalinger wrote:
> 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.