Re: [jetty-dev] SpinLock woes

[Mark Mielke <mark.mielke@xxxxxxxxx>]

On Tue, Jun 9, 2015 at 8:05 AM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

I re-ran my benchmarks with a simple body:

        long c=0;
        boolean even;
        try (Locker.Lock l = state.lock.lock())
        {
            c=state.count;
            even=state.count%2==0;
            state.count=++state.count%10000;
        }
        return even?c:-c;

The results I get are:

Benchmark                              Mode  Samples         Score   Error  Units
o.e.j.b.LockBenchmark.testLock        thrpt        2  37241687.930 ±   NaN  ops/s
o.e.j.b.LockBenchmark.testSpinLock    thrpt        2  45032559.188 ±   NaN  ops/s
o.e.j.b.LockBenchmark.testSync        thrpt        2  43886899.163 ±   NaN  ops/s

So for uncontested locks, I'm still seeing a benefit for SpinLock.

I'm not doubting your results, but the surprising part for me is that I believe "synchronized" uses some of the same techniques, only at a lower level (i.e. not byte code or JIT compiled byte code). In modern Java, "synchronized" should be doing the very thing that you do in SpinLock, including test-test-and-set. I expect Java  "biased locking" to do the same or better than your SpinLock:

http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.1

This makes me wonder if SpinLock is skipping anything important. For example... does the Java memory model guarantee a "happens before" relationship for AtomicReference? Or might AtomicReference only guarantee the state of the atomic reference? Research required...

Mostly, though, I bought Simone's argument that "B) we get free performance for each JDK major release;". I think if you can reliably and *safely* beat Java synchronized blocks, then your technique needs to be raised as a feature or bug against Java, as this could be a major win for the platform...