Removing intrinsic of Thread.isInterrupted() (original) (raw)

Christian Thalinger christian.thalinger at oracle.com
Tue Feb 25 10:26:28 PST 2014

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.

More information about the hotspot-compiler-dev mailing list