Submitted by: Omer & Ofer Kiselov Supevised by: Dmitri Perelman Networked Software Systems Lab Department of Electrical Engineering, Technion

 Transactional Memory solution ◦ An abstraction for critical sections in concurrent programming – transactions. ◦ Easier and more intuitive for programmers than locks. ◦ Implemented in both hardware and software.  The transaction abstraction ◦ Each critical section is executed optimisticly. ◦ Commit – Apply changes if correctness is maintained. ◦ Abort – discard and rollback otherwise. ◦ Aborts cause work waste and damages performance.  Some aborts are necessary ◦ Commit may cause incorrect results.  And some are not, and could be avoided ◦ Validating correctness is too complex to check through runtime.

 Build a software analysis tool: ◦ Abort statistics for a given run. ◦ Unnecessary abort ratio. ◦ Wasted work amount.  Will it pay of to add designs to stop the unnecessary aborts?  System is divided to two parts: ◦ Online part to execute and log an STM program. ◦ Offline part to read and analyze the log.

 Modify Deuce STM to log the run ◦ Insertion of logging commands to Deuce transactions code.  Transactions may call Logger class on reads, writes, commits and aborts ◦ Logger writes log in XML format  Runs on 32-core system for high parallelism Logger Deuce Framework Transactions Code: Start Read Write Commit A Perfectly Scalable Code Log Collector iterates through the loggers, collecting data about actions by their order.

 Read the log file and measure statistics: ◦ Count aborts by their causes.  Maintain a precedence graph to check dependencies ◦ Speculatively add aborted transactions’ edges to check abort necessity.

 Parallelism increase → Abort rate and unnecessary abort rate increases. ◦ Unnecessary abort rate relatively stable.  Paralleism increase → More aborts are caused by locked objects.  To improve performance over highly concurrent environements, more designs are required to reduce the unnecessary aborts.