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@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
