Iceberg: A Tool for Static Analysis of Java Critical Sections Michael D. Shah, Samuel Z. Guyer Tufts University Soap Workshop Session II, 10:50-11:10am, June 14, 2016

Categories of Concurrency Work Correctness o Race Conditions o Deadlock Performance o Scalability o Occasional problems

Categories of Concurrency Work Correctness o Race Conditions o Deadlock Performance o Scalability o Occasional problems

The Problem Real world coders may not always understand the performance of their code in critical sections.

Critical Section An area of code protected by a ‘lock’ o ad-hoc synchronization In Java, done with keyword ‘synchronized’ o We are focusing on finding methods that are synchronized

Critical Section An area of code protected by a ‘lock’ o ad-hoc synchronization In Java, done with keyword ‘synchronized’ o We are focusing on finding methods that are synchronized

What is in a Critical Section? High latency operations o I/O o Garbage Collection Amortized cost operations o Rehash, expand array-list Unexpected actions o Error handling or logging Over-synchronization o Irrelevant work

Our Soot based Tool: Iceberg Compile with Java compiler Transform Bytecode with Soot Build Call Graph Mark Critical Sections Gather Features of Critical Sections Output Summary and Graph

Code Metrics Collected on 24 Real World Programs Nested Methods Nested Loops Contains Allocations Large Line Count Branches Java Library Method

Sample Method

Synchronized Method

Visualization Aids Synchronized Method

Sample Method - Metrics # of methods in first level – 6 Total # of method calls – Total # of synchronized methods in first level – 3 Total # of synchronized method calls – 240 Total number of Java Library Calls – Number of allocations in first level – 0 Total number of allocations – 3030 Total number of lines of iR

Sample Method - Metrics # of methods in first level – 6 Total # of method calls – Total # of synchronized methods in first level – 3 Total # of synchronized method calls – 240 Total number of Java Library Calls – Number of allocations in first level – 0 Total number of allocations – 3030 Total number of lines of iR

Sample Method - Metrics # of methods in first level – 6 Total # of method calls – Total # of synchronized methods in first level – 3 Total # of synchronized method calls – 240 Total number of Java Library Calls – Number of allocations in first level – 0 Total number of allocations – 3030 Total number of lines of iR

Performance Pitfalls Over Synchronization o Too liberal use of ‘synchronized’ Large Critical Section o Lots of method calls Nested Critical Section o Many locks obtained

Are Developers Aware of Code Size? Our analysis is conservative, and static Does not handle reflection cases BUT, it appears call trees could possibly be very deep in worse case scenario o We compute maximum depth o (Other features like max children)

Results Critical sections can often be bigger than you think Libraries hide a lot of code o Including nested critical sections

Future Work – Static Analysis Integrate Static Analysis into IDE o Highlighting potential bad paths Collecting more code metrics

Future Work – Dynamic Analysis Dynamic analysis to measure actual time o Build actual call graph of program execution Latency variability analysis o Identify slow vs fast paths Concolic Testing o Force programs down “bad” paths

Thank You! Questions and Feedback? Contact: o o michaeldshah.net

Why Care About Performance Mobile Servers Games Image Sources: