1. JVSTM and its applications João Cachopo @ Software Engineering Group

2. J ava V ersioned S oftware T ransactional M emory

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

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

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

11. No inconsistent reads (JVSTM ensures opacity)

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

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

28. What about small transactions?

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

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)

51. FF-based (1000 items)

52. Original JDBC-based (10000 items)

53. FF-based (10000 items)

54. Some Fénix statistics

55. Normal week

56. February 2010

57. 17th to 19th No way we could get this before

59. ReadsWritesConflicts Normal day 898 80215 3309 17th February 3 306 600116 651745