Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] SpinLock woes

@Mark,

While i can see spinlock benefits in micro benchmarks, I'm not seeing them reflected in any macro ones. So any affect is either too small or an artifact I'd the micro benchmark.

We have probably got the main benefit from spinlock by making the body of each use the absolute minimal. We were probably a lot more rigorous because we knew it was a spin lock.  Once you do that any lock that tried some spins is going to do ok because the contended section is so small.

We just have to not get lazy again and have long held locks.

On 11 Jun 2015 1:56 am, "Mark Mielke" <mark.mielke@xxxxxxxxx> wrote:

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:


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...



_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

Back to the top