[논문 리뷰] Don't sit on the fence: A static analysis approach to automatic fence insertion

Jade Alglave, Daniel Kroening외 2명|arXiv (Cornell University)|2013. 12. 05.

Parallel Computing and Optimization Techniques인용 수 39

한 줄 요약

이 논문은 x86-TSO, Power, ARM와 같은 약한 메모리 아키텍처에서 동시성 프로그램의 순차적 일관성(sequential consistency)을 보장하기 위해 메모리 팔링(fences)을 자동으로 삽입하는 정적 분석 도구인 musketeer를 제시한다. 축약된 실행 그래프에서 아ksiomatic 의미론을 사용해 임계 사이클을 탐지함으로써 높은 정밀도와 확장성을 달성하였으며, memcached(10,000 LoC)와 같은 대규모 코드베이스를 매우 낮은 성능 오버헤드로 성공적으로 분석하였다.

ABSTRACT

Modern architectures rely on memory fences to prevent undesired weakenings of memory consistency. As the fences' semantics may be subtle, the automation of their placement is highly desirable. But precise methods for restoring consistency do not scale to deployed systems code. We choose to trade some precision for genuine scalability: our technique is suitable for large code bases. We implement it in our new musketeer tool, and detail experiments on more than 350 executables of packages found in Debian Linux 7.1, e.g. memcached (about 10000 LoC).

연구 동기 및 목표

• 약한 메모리 아키텍처에서 실행되는 동시성 프로그램에 대해 메모리 팔링을 수동으로 배치하는 것은 실수를 유발하기 쉬우며 아키텍처에 따라 다르게 적용되어야 하는 도전 과제를 해결하기 위해.
• 동적 또는 순서 교환 기반 방법의 상태 공간 폭발 문제를 피하면서도 확장 가능한 팔링 삽입 솔루션을 개발하기 위해.
• 프로그램 실행에서 임계 사이클을 정확하게 탐지하여 순차적 일관성(SC)을 강제함으로써 정확성을 확보하기 위해.
• 실제 코드베이스인 memcached와 liblfds 데이터 구조물에서 다양한 팔링 삽입 전략의 성능 영향을 평가하기 위해.
• 다양한 아키텍처에서 기존 팔링 삽입 기법을 통합된 비교 프레임워크로 제공하기 위해.

제안 방법

• 논문 [AMSS10]의 아ксиomatic 의미론을 사용하여 약한 메모리 동작을 모델링하고, 순차적 일관성의 최소 위반으로서 임계 사이클을 정의한다.
• 모든 가능한 프로그램 실행을 과도하게 근사하는 추상 실행 그래프(aeg)를 구성함으로써 잠재적 레이스 컨dition의 정적 분석을 가능하게 한다.
• aeg 내의 의존성과 데이터/제어 흐름을 분석하여 임계 사이클을 탐지하며, 팔링이 없이 SC가 위반될 수 있는 지점을 식별한다.
• 사이클에 중요한 위치에 팔링을 삽입하여 사이클을 끊고 SC를 복원하며, 아키텍처에 맞는 팔링 유형(예: x86의 mfence, ARM의 dmb, Power의 sync)을 사용한다.
• 이 방법은 x86-TSO, Power, ARM 등 여러 아키텍처를 지원하며, 단순한 수량을 넘어서 팔링 유형 간 비용 차이를 고려한다.
• 이 방법을 구현한 도구 musketeer는 실제 코드베이스와 통합되며, 374개의 Debian Linux 7.1 실행 파일을 포함한다.

실험 결과

연구 질문

• RQ1 정적 분석 접근법이 memcached(10,000 LoC)와 같은 대규모 실세계 코드베이스에 대해 높은 팔링 배치 정밀도를 유지하면서도 확장성 있는가?
• RQ2 musketeer의 팔링 삽입 전략이 매 메모리 접근 후 팔링을 삽입하는 난이도 높은 전략에 비해 성능 오버헤드는 얼마나 되는가?
• RQ3 musketeer는 fence 수와 실행 시간 측면에서 pensieve, Visual Studio 2013, dfence와 같은 기존 도구보다 뛰어나게 성능을 발휘하는가?
• RQ4 다양한 팔링 삽입 전략이 스택과 큐와 같은 동시성 데이터 구조물에서 런타임 성능에 미치는 영향은 어느 정도인가?
• RQ5 완전한 동적 실행 탐색 없이도 아ksiomatic 의미론 모델이 임계 사이클을 효과적으로 탐지하는 데 사용될 수 있는가?

주요 결과

• musketeer는 memcached(9,944 LoC) 포함 374개의 실세계 Debian 실행 파일을 성공적으로 분석하였으며, TSO에서는 13.9초, Power에서는 89.9초의 팔링 시간을 기록하였다.
• memcached의 경우, TSO에서는 단 3개의 팔링, Power에서는 70개의 팔링만 삽입하여 (e) 또는 (h)와 같은 난이도 높은 전략보다 훨씬 적은 수의 팔링을 사용하였다.
• musketeer로 팔링된 코드를 사용한 memcached의 런타임 오버헤드는 모든 SC 보장 전략 중에서 가장 낮았으며, x86에서는 평균 0.6%, ARM에서는 0.2%였다.
• liblfds 스택과 큐 벤치마크에서 musketeer의 오버헤드는 x86에서 0.6%, ARM에서 0.2%였으며, pensieve(3.2% 및 5.8%)와 Visual Studio(1.5% 및 4.2%)를 모두 능가하였다.
• ptunnel(1,867개 노드를 가진 aeg)과 같은 복잡한 프로그램에도 확장성 있었지만, 사이클 폭발로 인해 Power에서는 타임아웃이 발생하여 매우 복잡한 경우의 한계를 보여주었다.
• musketeer의 팔링 삽입은 정적 방법 중에서 가장 정밀하였으며, 동적 도구인 dfence와 동일한 벤치마크에서 속도와 팔링 수 모두에서 뛰어난 성능을 발휘하였다.