JVSTM and its applications

1. JVSTMand its applications • João Cachopo @ Software Engineering Group

2. Java Versioned Software Transactional Memory

3. First developed in 2005 (web page not update since 2006)

4. Outline • Original design of the JVSTM • Recent changes to the JVSTM • What we have been doing with it

5. First multi-version STM Designed for very large transactions and high read/write ratio

6. The goal: ease of programming (without incurring into too much overhead)

7. It is not a transparent STM

8. B previous: previous: previous: null VBox<T> body: value: 2 value: 1 value: 0 + T get() + put(T value) version: 13 version: 8 version: 4 Versioned Boxes

9. B previous: previous: previous: null body: value: 2 value: 1 value: 0 version: 13 version: 8 version: 4 Versioned Boxes GCed when no longer needed

10. B previous: null body: value: 2 version: 13 Versioned Boxes Reading a box: - follow body - compare version - return value - wait-free - no sync actions - no allocation

11. No inconsistent reads (JVSTM ensures opacity)

12. Because of GC Read-only txs • Begin Tx (lock-free) • Read boxes (wait-free) • Commit / abort Tx (lock-free) Entire TX lock-free

13. Read-only transactions never conflict (MV-permissiveness)

14. Read-write txs • Begin Tx (lock-free) • Read / write boxes (wait-free) • Abort Tx (lock-free) • Commit Tx (global lock)

15. Lock-based commit commit() { GLOBAL_LOCK.lock(); try { } finally { GLOBAL_LOCK.unlock(); } }

16. Lock-based commit commit() { GLOBAL_LOCK.lock(); try { if (validate()) { } } finally { GLOBAL_LOCK.unlock(); } }

17. Lock-based commit commit() { GLOBAL_LOCK.lock(); try { if (validate()) { int newTxNumber = globalCounter + 1; writeBack(newTxNumber); globalCounter = newTxNumber; } } finally { GLOBAL_LOCK.unlock(); } }

18. Very simple design...

19. Works really well in practice

20. Lock-based commit commit() { GLOBAL_LOCK.lock(); try { } finally { GLOBAL_LOCK.unlock(); } } If uncontended, this is quite fast!

21. Good when few read-write txs or txs long enough so that commits do not overlap often

22. (machine with 196 physical cores)

23. Lock-based commit commit() { GLOBAL_LOCK.lock(); try { if (validate()) { } } finally { GLOBAL_LOCK.unlock(); } } We may do other things here...

24. Delay computations until commit time, if they cause many conflicts

25. STMBench7

26. STMBench7

27. STMBench7

28. What about small transactions?

29. Can we make it better? Read-write txs • Begin Tx (lock-free) • Read / write boxes (wait-free) • Abort Tx (lock-free) • Commit Tx (global lock)

30. Read-write txs • Begin Tx (lock-free) • Read / write boxes (wait-free) • Abort Tx (wait-free) • Commit Tx (lock-free)

31. JVSTM completely lock-free

32. Lock-free isn’t that hard...

33. Efficient and lock-free is!

36. JVSTM still not optimized for tiny transactions

37. We’re working on it • Eliminate memory allocation • Stealth transactions • Make beginTx wait-free • Optimize fast path of read/write • Versioned arrays • ...

38. JVSTM applications?

39. More recently • STM-based Thread Level Speculation • Dynamic Software Updates • Automatic memoization of functions with side-effects

40. This led to • Transactional • collections (queues, maps, sets, etc) • I/O streams • Inevitable transactions • Exploring failure atomicity • ...

41. But it all started with the FénixEDU system (> 1 million LOCs)

42. First real-world application of STMs

43. The Fénix Framework

44. Simplify the development of applications with a transactional and persistent rich domain model (AKA enterprise applications)

49. Simpler programming model Better performance* Explores multicores

50. Original JDBC-based (1000 items)