On Sat, May 11, 2013 at 1:46 AM, Alexander Turner <nerdscent...@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@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
