Improving the speed of Thread interrupt checking

[Alexander Turner]

Charles,

It has been very illustrative looking at old code which was written to be
highly efficient of single core machines in this recent project (and then
changing it). My current working model of the evolution of JVM centric and
JVM threading code is that it all used locks which was slow. Then the locks
were replaced with futex/critical sections. On a single core machine - this
is an ideal solution and trumps CAS only solutions in many cases. However,
as we are now almost exclusively in the multi-core world, futex contention
is much higher and starts to cause problems.

On a multi-core machine, even light contention causes real contention and
real quantum loss on locks and so everything changes. I am personally very
interested indeed in any insights you might get from looking elsewhere in
the JVM.

Cheers - AJ


On 11 May 2013 09:09, Charles Oliver Nutter <headius at headius.com> wrote:

> 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
>
>
> _______________________________________________
> 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/20130511/5a276ec2/attachment-0001.html