메모리: 다섯 전략, 하나의 선택

메모리 관리는 Mere 같은 언어에 결정적인 선택이며, 그 답은 철학에서 곧바로 나온다 —— 숨기지 않는다. GC도 단일 소유권 방식도 아니라, 프로그래머가 작은 전략 집합 —— owned·borrowed·arena·region·stack —— 에서 고르고, 그 선택이 타입에 보인다. 왜 단일 전략으로는 이길 수 없는가, 그리고 왜 선택을 명시하는 것이 핵심인가.

merememory-modelownershipregionslanguage-design

암묵적인 것을 명시적으로 만들려는 언어에게, 메모리는 첫 진짜 시금석이다. 그것은 고전적인 숨은 비용이다: 값이 어디에 살고, 누가 소유하며, 언제 해제되는가 —— 대부분의 언어는 그 무엇도 생각하지 않아도 되게 하고, 그 편리함의 대가를 멈춤·누수·해제 후 사용으로 치른다. Mere는 메모리를, 바로 자신의 철학이 “드러내라”고 말하는 종류의 것으로 다룬다.

설계 공간

메모리를 관리하는 방법은 넘친다. 그리고 저마다 “이것을 누가, 언제 해제하는가?“에 대한 다른 답이다.

  • 가비지 컬렉션 —— 런타임이 정한다. 쓰기는 쉽지만, 할당과 소유권이 보이지 않게 되고, “언제”는 당신의 제어 아래 있지 않다.
  • 수동 —— 당신이 명시적으로 정한다. 완전한 제어, 안전성 없음.
  • 소유와 대여 —— 단일 소유자, 참조로 대여, 소유자가 스코프를 벗어나면 해제. 안전 하고 정밀하지만, 의식(儀式)의 대가를 치른다. 특히 공유가 많은 그래프 형태 데이터에서.
  • 아레나 / 리전 —— 많은 것을 하나의 영역에 할당하고, 영역째로 한꺼번에 해제한다. 수명을 공유하는 객체 뭉치 —— AST, 요청, 프레임 —— 에 훌륭하고, 수명이 맞지 않을 때는 최악이다.

어느 것도 모든 곳에서 이기지는 못한다. 소유권은 명확한 단일 소유자를 가진 값에는 아름답고, 서로 참조하는 노드의 그물에는 괴롭다. 아레나는 그 그물에는 완벽하고, 뭉치를 넘어 살아남는 장수명 값에는 쓸모없다. GC는 그 모두를 덮어 가리고, 그렇게 함으로써 Mere가 보이게 하고 싶은 바로 그것을 숨긴다.

Mere의 답: 고른다, 그리고 선택을 명시한다

어느 단일 전략도 모든 곳에서 옳지 않으므로, Mere는 당신을 위해 하나를 고르지 않는다. 작은 집합을 제공하고, 프로그래머에게 데이터마다 고르기를 요구한다. 선택은 타입에 실린다. 최초의 설계 공간은 다섯 전략이었다:

  1. owned —— 단일 소유자. 옮기면 옛 바인딩은 무효가 된다(Rust처럼). 명확한 거처가 하나 있는 값을 위해.
  2. borrowed —— 소유권을 취하지 않고 참조로 접근한다. 공유형이나 가변형으로. 데이터를 넘겨주지 않고 전달하기 위해.
  3. arena —— 이름 붙은 아레나에 할당한다. 그 안의 모든 것이 한꺼번에 해제된다. 그래프 형태 데이터에 이상적이고, 한 아레나 안의 상호 참조는 자유롭다.
  4. region —— 블록에 수명이 묶인 스코프 있는 영역.
  5. stack —— 평범한, 자동인 경우.

중요한 것은 목록이 아니다. 전략이 침묵하지 않는다는 것이다. 아레나에 사는 값은 그것을 타입에 말한다. 대여 참조는, 그것이 빌린 바로 그것과는 다른 타입이다. 소유권을 문맥에서 어림하거나 관례를 믿지 않는다 —— 읽는다. 이것은 언어의 다른 모든 곳과 같은 베팅을, 프로그램이 가장 자주 틀리는 자원에 적용한 것이다.

타협을, 이름을 붙여

첫 회에서 Mere는 트레이드오프를 없는 척하지 않고 이름을 붙인다고 약속했다. 이번 장의 그것을 솔직하게: 메모리 전략을 고르는 것은 GC에 맡기는 것보다 손이 간다. 수명을 생각해야 하고, 타입 시스템이 그것을 지키게 하며, GC라면 사소한 패턴 몇몇은 스스로 설계하는 것이 된다. Mere는 그 비용을 일부러 받아들인다. 왜냐하면 그것이 사는 것 —— 프로그램을 읽고 메모리의 행방을 알 수 있는 것, 당신을 대신해 조용히 정하는 런타임이 없는 것 —— 이야말로 최적화하고 있는 바로 그것이기 때문이다. 그리고 소유권 표기가 요구하는 장황함은, 첫 회대로, 여기서는 값싼 자원이다.

이다음

다섯 전략은 설계가 시작된 곳이지, 착지한 곳이 아니다. 늘어놓아 보니 곧, 이후 장이 답할 물음이 섰다:

  • arena와 region은 의심스러울 만큼 닮았다 —— 정말 둘 다 필요한가? (다음 회는 그것을 하나로 접는 이야기다.)
  • 애초에 누가 아레나에 들어갈 수 있는가? 전부는 아니다: OS 자원을 지닌 값은 포인터를 리셋하는 것만으로는 해제할 수 없다. 그 제약 —— Trivial 이라 부른다 —— 과, 정리가 정말로 필요한 값을 위한 별도의 기계(Drop, with 로 실행)는 몇 회 뒤다.
  • “리전으로의 뷰”란 정확히 무엇을 뜻하는가? 그것은 독립된 작은 이론이 된다.

그러니 이번 회는 지도이지, 땅이 아니다. 땅 —— 그곳에 무엇이 살 수 있고 어떻게 정리되는지에 대한 분명한 규칙을 가진, 통합된 리전 모델 —— 을 Part II의 나머지가 쌓는다. 다음 회: 왜 arena와 region이 하나가 되었는가.

← Back to Mere: 언어를 만들다