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

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Feb 25 10:38:59 PST 2014

On 02/25/2014 10:26 PM, Christian Thalinger wrote:

On Feb 25, 2014, at 10:05 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

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(clearint): // (t == Thread.current() && (!TLS.osthread.interrupted || !clearint)) // ? TLS.osthread.interrupted : /slow path:/ t.isInterrupted(clearint) The first condition is not true in the test case so we always go slow-path.

Oh, that makes sense, thanks Christian! The updated test: https://github.com/shipilev/benchmarks-scratch/blob/master/src/main/java/org/sample/ThreadIsInterrupted.java

...on my Linux x86_64, JDK 7u40 yields:

Benchmark Mode Samples Mean Mean error Units current_disabled avgt 15 37.071 0.525 ns/op current_enabled avgt 15 2.041 0.029 ns/op other_disabled avgt 15 78.378 2.074 ns/op other_enabled avgt 15 78.454 5.141 ns/op

Given the order of magnitude difference for the method call which is frequently used in the tight loops, I think removing the intrinsic sets users up for the performance regression.

Thanks, -Aleksey.

More information about the hotspot-compiler-dev mailing list