Featherweight Monitors with Bacon Bits

Transcription

1 Featherweight Monitors with Bacon Bits David F. Bacon IBM T.J. Watson Research Center

2 Contributors Chet Murthy Tamiya Onodera Mauricio Serrano Mark Wegman Rob Strom Kevin Stoodley

3 Introduction It s the same old sad story: Java has threads and synchronized methods But synchronization is dog-slow So synchronization is optional Shoot the foot of your choice: Get bad performance, or Get bug-prone code

4 Its s Worse Than That Libraries must be thread-safe All non-trivial methods are synchronized Library call to set a bit in a bit vector:» ~50 instructions to lock and unlock the object» ~10 instructions method call overhead» ~5 instructions to actually set the bit Locking overhead frequently above 25% even in single-threaded applications!

5 Java Locking Overhead HPJ Alpha Time (seconds) Base NoSync NoCheck 2 0 trans javac jgl jacorb jobe toba javalex jax javacup Benchmark

6 Java Synchronization Features Thread can lock an object repeatedly locks nest nesting count must be kept On exception, thread must release locks call stack implicitly names all locked objects therefore, list of locked objects not needed

7 Locking Scenarios by Frequency Object is unlocked. We already locked the object a few times We already locked the object a lot of times Object is locked and we are the first to queue up Object is locked and other threads are waiting

8 Nested Locking Depth 100% 90% 80% 70% 60% 50% 40% Third Second First 30% 20% 10% 0% trans javac jgl jacorb jobe toba javalex jax javacup parser jolt espresso netrexx null

9 Repeated Locking (by depth) 100% 90% 80% 70% 60% 50% 40% 30% Third-Same Third-Different Second-Same Second-Different First-Same First-Different 20% 10% 0% trans javac jgl jacorb jobe toba javalex jax javacup parser jolt espresso netrexx null

10 Assumptions Atomic compare-and-swap available Thread objects aligned on 8-byte boundaries.

11 Why Fast (Un)locking is Hard Must atomically release lock and check queue Object classptr Thread 2 DATA Owner Queue Thread 1 Thread 3

12 Object 39 classptr DATA 1 3 Solution:Bacon Bit Lock Structure Thread Pointer 31 Thread Bacon bit 0: no one queued to lock 1: threads are queued Short Count 0-2: # of locks - 1 3: count is >= 3 and is stored in FatLock

13 Inline Lock Operation Must check: no one owns the lock inline void Monitor::enter() { if (! CompareAndSwap(lockWord, 0, thread)) outoflineenter(); }

14 How Locking Works thread LOCK thread Thread 1 Object 8 classptr 0 DATA 0 Thread 1 Object 8 classptr 0 DATA 0 UNLOCK

15 Inline Unlock Operation Must check: we own the lock lock count is 1 no one is waiting for the lock inline void Monitor::exit() { if (! CompareAndSwap(lockWord, thread, 0)) outoflineexit(); }

16 Race Conditions and Lock Transfer Problem: simultaneous unlock and enqueue Solution is in the Bacon bit always set if a thread is enqueued on object. never modified without acquiring globallock on locktable. all changes to monitor lockword must be via CompareAndSwap(). unless object and globallock are locked

17 void Monitor::enqueueForLock() { locktable.lock(); while (true) { unsigned temp = lockword; Enqueue Operation } } if (temp!= 0 && CompareAndSwap(lockWord, temp, temp BaconBit)) { mon = locktable.inflatemonitor(this); mon->addlocker(thread); locktable.unlock(); thread->suspend(); return; } if (CompareAndSwap(lockWord, 0, thread)) { locktable.unlock(); return; }

18 locktable globallock quickcells hashtable FatLock 1 monitor count locklist FatLock 2 monitor count locklist Object 3 classptr 0 0 DATA Before Enqueue by Thread 2 Thread 1 Thread 2 thread

19 locktable globallock quickcells hashtable FatLock 2 monitor count locklist FatLock 1 monitor 0 locklist Thread 2 After Enqueue by Thread 2 Object 3 classptr 1 0 DATA Thread 1 thread

20 Deeply Nested Locks When count reaches 3 lock globallock inflate monitor set long count to 3 don t set Bacon bit

21 locktable globallock quickcells hashtable FatLock 1 monitor count locklist FatLock 2 monitor count locklist Object 3 classptr Thread DATA Before Deep Nesting Thread 1 thread

22 locktable globallock quickcells hashtable FatLock 2 monitor count locklist FatLock 1 monitor 3 locklist Thread 2 Object 3 classptr 0 3 DATA After Deep Nesting Thread 1 thread

23 locktable globallock quickcells hashtable FatLock 3 monitor count locklist FatLock 4 monitor count locklist Big Example Object 15 Thread 1 classptr 0 1 DATA 8 FatLock 1 monitor 0 locklist thread Thread 2 Object 8 classptr 1 0 DATA 39 FatLock 2 monitor locklist Object 39 classptr 0 3 DATA Thread 3

24 Intel x86 Implementation (486 +) 7.5 cycles on Pentium forward jump to stub predicted not taken ; ebx is the this pointer LOCK: mov ecx, THREAD ; ecx = thread xor eax, eax ; eax = 0 cmpxchg [ebx], ecx ; C&S(lockWord, eax, ecx) jnz stub ; swap failed; try slowly lockdone: stub:call outoflinelock ; do it the slow way j lockdone ; and return

25 Problem: Deeply Nested Locks Each FatLock access locks the global lock decreases performance of recursive methods increases global lock contention Solution: cache deeply nested FatLock test for cache hit before locking global lock If it s a hit, we ve already locked the object

26 Problem: synchronized() blocks Synchronized methods are lexically nested synchronized() blocks become bytecodes: lexical nesting not checked by verifier throwing exception might not release locks synchronized(foo) { } javac monitorenter foo monitorexit foo

27 Solution for Non-nested Locking If possible, verify nesting at compile-time Else inflate monitor on non-nested lock set Bacon bit in lockword search locktable when thread is killed unlock does not need modification

28 Architectural Adaptations Uniprocessor with synchronous scheduler don t need C&S MOV Uniprocessor with asynchronous scheduler use atomic C&S in cache CMPXCHG Strongly ordered multiprocessor (Pentium) use atomic C&S in RAM LOCK#CMPXCHG Weakly ordered multiprocessor (Pentium Pro) atomic C&S and cache flush LOCK#CMPXCHG CPUID

29 Advantages of Bacon-bit Locks Absolutely minimal cost for common case 4 instructions/7.5 cycles on Pentium compare to 6 cycles for no-op CALL-RET Next most common case also very fast 10 instructions/17 cycles on Pentium Space overhead only 1 word per object Global lock only used in rare cases Co-exists with locks not lexically-nested

30 Advantages of Bacon-bit Locks Scalable (can partition global lock) Almost no spin locking required Lock acquisition is fair Same implementation works and is fast on synchronously scheduled uniprocessor asynchronously scheduled uniprocessor strongly ordered multiprocessor weakly ordered multiprocessor