Improving the speed of Thread interrupt checking

[Alexander Turner]

Charles,

Why bother even using CAS?

Thread A is monitoring Thread B. Thread B cooperatively checks to see if it
should die.

Therefore, you only need B to know when A has told it to shut down.

Therefore, all you need is a volatile boolean. A volatile boolean is very
much faster than a full CAS operation.
http://nerds-central.blogspot.co.uk/2011/11/atomicinteger-volatile-synchronized-and.html

Best wishes - AJ


On 10 May 2013 17:03, Charles Oliver Nutter <headius at headius.com> wrote:

> This isn't strictly language-related, but I thought I'd post here before I
> start pinging hotspot folks directly...
>
> We are looking at adding interrupt checking to our regex engine, Joni, so
> that long-running (or never-terminating) expressions could be terminated
> early. To do this we're using Thread.interrupt.
>
> Unfortunately our first experiments with it have shown that interrupt
> checking is rather expensive; having it in the main instruction loop slowed
> down a 16s benchmark to 68s. We're reducing that checking by only doing it
> every N instructions now, but I figured I'd look into why it's so slow.
>
> Thread.isInterrupted does currentThread().interrupted(), both of which are
> native calls. They end up as intrinsics and/or calling JVM_CurrentThread
> and JVM_IsInterrupted. The former is not a problem...accesses threadObj off
> the current thread (presumably from env) and twiddles handle lifetime a
> bit. The latter, however, has to acquire a lock to ensure retrieval and
> clearing are atomic.
>
> So then it occurred to me...why does it have to acquire a lock at all? It
> seems like a get + CAS to clear would prevent accidentally clearing another
> thread's re-interrupt. Some combination of CAS operations could avoid the
> case where two threads both check interrupt status at the same time.
>
> I would expect the CAS version would have lower overhead than the hard
> mutex acquisition.
>
> Does this seem reasonable?
>
> - Charlie
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130510/d70d0437/attachment.html