Improving the speed of Thread interrupt checking

[Charles Oliver Nutter]

On Sat, May 11, 2013 at 1:46 AM, Alexander Turner <nerdscentral at gmail.com>wrote:

> Thanks for the explanation. I have recently (for the last 6 months) been
> involved with some very performance centric multi-threaded work in
> profiling the JVM. Using JVMTI as a profiling tool with C++ underneath. The
> code all uses JVM locks where locks are required - but as profilers need to
> be as invisible as possible I have been removing locks where they can be
> avoided.
>
> My experience here has indicated that on modern machies CAS operations are
> always worth a try compared to locks. The cost of loosing the current
> quantum (even on *NIX) is so high that it is not worth paying unless a
> thread is truly blocked - e.g. for IO.
>
...


> In your case, inter-thread signalling is definitely not work loosing a
> quantum over.
>
> If I get chance over the next couple of days I'll make great a cut down
> example of CAS over thread.interup and run the profiler (DevpartnerJ) over
> it - it could be a great unit test.
>

Yes, it could be illustrative. Finding this code in Hotspot also makes me
wonder what other VM-level state is "excessively guarded" by using locking
constructs instead of lock-free operations like CAS.

The code involved is also not particularly complex. I may see if I can hack
in a CAS version of the interrupt check+clear logic and see how things look
as a result. The next step would be moving that CAS directly into the
intrinsic, so it can optimize along with code calling it.

- Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130511/5e924580/attachment.html