SwitchPoint is indeed an option, and I have used it in JRuby's compiler to reduce the frequency of checking for interrupt events.
However in this case it is just a plain old library written in plain old Java that supports Java 6+. Using Indy stuff isn't really an option. Plus...it doesn't solve the performance issue of Thread.interrupted anyway :-) - Charlie (mobile) On May 10, 2013 5:48 PM, "Remi Forax" <fo...@univ-mlv.fr> wrote: > 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 >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
