Removing intrinsic of Thread.isInterrupted()

Aleksey Shipilev aleksey.shipilev at
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> 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(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.

Oh, that makes sense, thanks Christian! The updated test:

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


More information about the hotspot-compiler-dev mailing list