The Application of Static Analysis to Optimize the Dynamic Detection of Race Conditions Yakov Roskoshnyy, Dmitry Tsitelov, Vitaly Trifanov, Roman Elizarov,Saint Petersburg State University of Information Technologies, Mechanics and Optics, Saint Petersburg 12 - 14 November 2015 Tools and Methods of Program Analysis in St. Petersburg

1. Применение статического анализа
для оптимизации динамического
поиска гонок
Яков Роскошный
Университет ИТМО
Дмитрий Цителов, Виталий Трифанов, Роман Елизаров
OOO "Эксперт-Система"

2. Гонки
• При отсутствии синхронизации между
двумя потоками может возникнуть гонка
• Результат работы программы будет
недетерминирован.

3. Ожидаемое выполнение

4. Гонка

5. Методы автоматического поиска
гонок
• Анализ кода программы без
её запуска.
• NP-трудная задача.
Статический
• Анализирует текущий путь
выполнения.
• Большие накладные расходы.
Динамический

6. Динамический детектор jDRD
• Основан на отслеживании отношения
happens-before с помощью векторных
часов.
• Основная проблема – накладные расходы.
• В частности, необходимость
контролировать все обращения к
разделяемым переменным, по которым
возможна гонка.
• Можно применить статический анализ для
сужения области анализа jDRD.

7. Шаблоны обеспечения
синхронизации
Неизменяемые
объекты
Безопасная
публикация объекта
без последующих
изменений
Безопасная
публикация объекта
Объект,
принадлежащий
потоку
Внутренне
синхронизированное
поле

8. Thread confinement
• Объект не покидает контекст одного потока.
• При обращении к таким объектам
невозможна гонка.
String a() {
StringBuilder sb = new StringBuilder();
…
return sb.toString();
}

9. Безопасная публикация объекта
• Поля класса, экземпляры которого
передаются потоку, и затем не покидают
его пределов.
Runnable task = new Runnable() {
…
}
new Thread(task).start();

10. Безопасная публикация объекта без
последующих изменений
• Поля класса инициализируются на начальном
этапе конфигурации, а затем только читаются.
• Типичный представитель – конфигурация
приложения, доступная через статический
контекст.
• Гонки по таким полям могут возникнуть только
при отсутствии синхронизации между
начальной инициализацией объектов данного
класса и их дальнейшим использованием.

11. Локальные свойства
• Шаблоны
– Объект, принадлежащий потоку
– Безопасная публикация объекта
– Безопасная публикация объекта без последующих
изменений
• Доказательство теории об отсутствии гонок по
полю относится к некоторой ограниченной
области кода или зависит от точки
порождения объекта.
• Отсутствие гонок может быть гарантировано
только для некоторых объектов класса.

12. Неизменяемые объекты
• Все их поля final и ссылка на объект не
«утекает» при конструировании.
• Не изменяют своего состояния после
конструирования.
• String, Number.
• jDRD исключает такие объекты из анализа.

13. Внутренне синхронизированное
поле
class A {
final Object lock = new Object() ;
private int x; //Internally Synchronized
void incX() {
synchronized(lock) {
x++;
}
}
void setX(int val) {
synchronized(lock) {
x = val;
}
}
}

14. Глобальные свойства
• Шаблоны
– Неизменяемые объекты
– Внутренне синхронизированное поле
• Не зависит от экземпляра объекта и
контекста использования.
• Можно исключить из динамического
анализа все обращения к этому полю.

15. Поиск внутренне синхронизированных полей
Получение control flow graph
Выделение множества
возможных блокировок
Обход СFG

16. Промежуточное представление
Shimple
• Стек полностью заменен на локальные
переменные.
• SSA(Static single assignment) представление.
Каждая переменная имеет единственное
место присваивания.
• Операции сгруппированы.
• http://sable.github.io/soot/

17. Пример CFG
void a() {
int x = 3;
int y = 5;
while (y < 5) {
y += x – 1;
}
System.out.println(y);
}

18. Получение множества возможных
блокировок
• Данная часть алгоритма необходима для
предотвращения ложных срабатываний.
• Если переменная была инициализирована
как φ-функция, или как не final поле, то она
не может являться блокировкой.

19. Обход CFG
• При обходе поддерживаем множество взятых в
текущий момент блокировок – curLocks .

20. Обход CFG
• Для каждого поля f сохраним множество
блокировок, с которыми к нему обращались -
f.locks.

21. Обход CFG
• Для каждой вершины CFG будем хранить
множество блокировок, с которыми мы
посещали данную вершину – v.locks .

22. Блокировки для методов
• Вызовы методов, аналогично обращению к
полям, также могут быть защищены
блокировкой.
• Аналогичным анализом можно выделить
блокировки для методов
• Затем использовать их при анализе полей.

23. Результаты
Приложение Общее число полей Защищенных полей Процент
dxFeed 5212 982 19
MARS 2311 477 21
Tomcat 6793 1546 23
jtt 1165 176 15
Приложение Общее число полей Защищенных полей Процент
dxFeed 1555 89 6
MARS 545 20 4
Tomcat 2924 132 5
jtt 405 28 7
Результаты без учета final полей.
Полученные результаты.

24. Перспективы
• Поиск локальных свойств.
• Результаты анализа могут
быть использованы для
поиска некоторых ошибок
синхронизации.