On 05/10/2013 06:03 PM, Charles Oliver Nutter 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
Hi Charles, if a long-running expression is an exception, I think it's better to use a SwitchPoint (or a MutableCallsite stored in a static final field for that). Each regex being parsed first register itself in a queue, a thread wait on the first item of the queue, it the time is elapsed, the SwitchPoint is switch-off, so each thread Joni parsers knows that something goes wrong and check the first item. The parser which timeout, remove itself from the queue and create a new SwitchPoint. So the check is done only when a parser run too long. Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
