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

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Feb 25 10:05:46 PST 2014

• Previous message: Removing intrinsic of Thread.isInterrupted()
• Next message: Removing intrinsic of Thread.isInterrupted()
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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.

• Previous message: Removing intrinsic of Thread.isInterrupted()
• Next message: Removing intrinsic of Thread.isInterrupted()
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the hotspot-compiler-dev mailing list