Removing intrinsic of Thread.isInterrupted()

[Aleksey Shipilev]

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