[논문 리뷰] dup -- Explicit un-sharing in Haskell

Joachim Breitner|arXiv (Cornell University)|2012. 07. 09.

Security and Verification in Computing참고 문헌 7인용 수 3

한 줄 요약

이 논문은 소스 코드를 수정하지 않고도 게으른 데이터 구조에서 공유를 끊는 데 사용할 수 있는 두 가지 명시적 언쉐어링 연산인 dup 및 deepDup을 Haskell에서 소개한다. 박스형식으로 값을 감싸거나 힙에 할당된 써머를 재귀적으로 복사함으로써 이들 기초 연산은 의도하지 않은 큰 데이터 구조의 유지로 인한 메모리 누수를 방지하여, 깊은 재귀가 수반되는 트리 순회와 같은 상황에서 일정한 메모리 사용을 가능하게 한다.

ABSTRACT

We propose two operations to prevent sharing in Haskell that do not require modifying the data generating code, demonstrate their use and usefulness, and compare them to other approaches to preventing sharing. Our claims are supported by a formal semantics and a prototype implementation.

연구 동기 및 목표

• 의도하지 않은 큰 데이터 구조의 공유로 인한 게으른 함수형 프로그램에서의 공간 누수 문제를 해결하기 위해.
• 원본 데이터 생성 코드를 수정하지 않고도 프로그래머가 직접 제어할 수 있는 방식으로 공유를 끊는 메커니즘을 제공하기 위해.
• 가비지 컬렉션으로 인한 데이터 유지로 인한 오버헤드가 문제가 되는 성능에 민감한 응용 프로그램을 위한 실용적인 해결책을 제공하기 위해.
• Launchbury의 자연 의미론을 사용하여 언쉐어링 연산의 동작을 형식화하고 그 정당성을 증명하기 위해.
• 수정되지 않은 GHC를 대상으로 한 프로토타입 구현을 통해 실현 가능성과 타당성을 입증하기 위해.

제안 방법

• 사용 시점에서 공유를 끊기 위해 값을 Box 형식으로 감싸는 dup 기초 연산을 도입한다.
• 입력 값이 참조하는 힙에 할당된 모든 써머를 게으르게 복사하는 재귀적 변형인 deepDup을 제안한다.
• 폐쇄를 힙에서 복사하기 위해 고유의 C--/Cmm 구현을 사용하여 평가 순서를 유지하고 공유된 써머가 남지 않도록 보장한다.
• 모든 포인터를 포함한 폐쇄를 스택 기반의 폐쇄 복사 루프로 처리하여 새로운 힙에 할당된 복사본을 생성한다.
• 정적 써머나 코드 세그먼트를 수정하지 않아 가비지 컬렉터를 손상시키지 않는 런타임 메커니즘을 설계한다.
• 수정되지 않은 GHC와 통합된 프로토타입을 구현하여 호환성과 정확성을 입증한다.

실험 결과

연구 질문

• RQ1 소스 변환 또는 컴파일러 수정 없이도 Haskell에서 명시적 언쉐어링을 달성할 수 있는가?
• RQ2 게으른 평가와 가비지 컬렉션 환경에서 언쉐어링을 안전하게 구현할 수 있는가?
• RQ3 게으른 평가의 맥락에서 dup 및 deepDup의 형식적 의미론은 무엇인가?
• RQ4 deepDup은 평가 후에 반환 값에 의해 참조되는 것 외에는 어떤 힙 객체도 유지하지 않음을 보장할 수 있는가?
• RQ5 실제로 dup 및 deepDup를 사용할 경우의 성능 및 메모리 상호 간의 상충 관계는 어떠한가?

주요 결과

• 프로토타입 구현은 수정되지 않은 GHC와 성공적으로 통합되었으며, 예제에서 공간 누수를 정확히 방지하였다.
• deepDup를 사용할 경우, main의 마지막 줄을 제거했을 때 프로그램의 메모리 사용량이 4.189 GB에서 2 MB로 감소하여 효과적인 언쉐어링이 이루어졌음을 입증하였다.
• Launchbury의 자연 의미론 프레임워크 내에서의 형식적 의미론은 deepDup가 평가 후에 반환 값에 의해 참조되는 것 외에는 어떤 힙 객체도 유지하지 않음을 보장함을 증명하였다.
• 이 구현은 재귀적 데이터 구조를 정확히 처리하며, 참조된 폐쇄를 게으르게 복사함으로써 공유된 써머 문제를 피한다.
• 순수 함수형 코드에서는 안전하지만, unsafePerformIO나 레이지 I/O를 사용할 경우 중복된 써머에서 발생하는 부작용으로 인해 손상될 수 있다.
• 현재 정적 써머는 런타임 표현 구조의 제약로 인해 복사되지 않지만, 향후 지원을 위한 잠재적 확장 방안을 논문에서 제안하고 있다.