Improving the speed of Thread interrupt checking

[Charles Oliver Nutter]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130510/2b94cd60/attachment.html