Improving the speed of Thread interrupt checking

[Charles Oliver Nutter]

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" <forax at 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 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/8736fd27/attachment.html