Erlang 또는 Elixir 시스템을 시작하면 Erlang 런타임 시스템을 실행하는 OS 프로세스가 하나 생성되며, 그 OS 프로세스 안에서는 BEAM VM이 여러 Erlang 프로세스를 실행합니다. 이렇게 실행 중인 런타임 시스템 인스턴스를 Erlang 노드라고 부르며(ERTS를 실행하든 Erlang의 다른 구현체를 실행하든 관계없습니다 — Section 1.4 참조), 같은 네트워크나 심지어 같은 호스트 머신에서 실행 중일 수 있는 다른 Erlang 노드와 구별하기 위해 이름을 붙일 수 있습니다. Java 세계에서 이에 해당하는 것은 JVM 인스턴스입니다. 그러나 Erlang에는 투명한 분산이라는 개념도 내장되어 있어, Erlang 노드들을 네트워크를 통해 서로 연결하여 클러스터를 구성할 수 있습니다.

따라서 BEAM 애플리케이션 코드는 항상 Erlang 노드의 컨텍스트 안에서 실행되며, 노드의 모든 계층이 애플리케이션의 성능에 영향을 미칩니다. 노드를 구성하는 계층 스택을 살펴보겠습니다. 이를 통해 다양한 환경에서 시스템을 실행할 때 어떤 선택지가 있는지 이해할 수 있을 것입니다.

Erlang OTP 문서에 따라 완전히 정확하게 말하자면, 노드는 실제로는 이름이 부여되어 클러스터에 참여할 준비가 된, 실행 중인 런타임 시스템입니다. 즉, 명령줄 스위치 --name NAME@HOST 또는 --sname NAME 중 하나(Erlang 런타임의 경우 -name 및 -sname)로 이름을 지정하지 않고 Elixir를 시작하면, 엄밀히 말해 런타임은 있지만 노드는 없는 상태가 됩니다. 이러한 시스템에서는 Node.alive? 함수(Erlang에서는 is_alive())가 false를 반환합니다.

런타임 시스템 자체는 용어를 그다지 엄격하게 사용하지 않습니다. 노드에 이름을 지정하지 않았더라도 노드의 이름을 조회할 수 있습니다. Elixir에서는 Node.list 함수를 :this 인자와 함께 사용하고, Erlang에서는 nodes(this)를 호출하거나 간단히 node()를 호출하면 됩니다:

이 책에서는 이름이 부여되었는지와 관계없이 실행 중인 런타임의 모든 인스턴스를 노드라는 텀으로 부르겠습니다.

이 책의 Part I에서는 ERTS의 구성 요소에 관한 모든 것을 배웁니다. Part II에서는 Erlang 노드를 실행하고, 검사하고, 디버깅하고, 프로파일링하는 방법을 설명합니다. 소스에서 Erlang을 빌드하는 방법은 Appendix A를 참조하십시오.

여러분의 애플리케이션은 하나 이상의 노드에서 실행되며, 프로그램의 성능은 애플리케이션 코드뿐만 아니라 ERTS 스택 안에서 여러분의 코드 아래에 있는 모든 계층에도 좌우됩니다. Figure 1에서는 한 머신에서 두 개의 Erlang 노드가 실행되는 모습으로 ERTS 스택을 나타낸 그림을 볼 수 있습니다.

Elixir를 사용한다면 스택에 계층이 하나 더 있습니다.

스택의 각 계층을 살펴보고, 애플리케이션의 요구에 맞게 각 계층을 어떻게 튜닝할 수 있는지 알아봅시다.

스택의 맨 아래에는 여러분이 사용하고 있는 하드웨어가 있습니다. 애플리케이션의 성능을 개선하는 가장 쉬운 방법은 아마도 더 좋은 하드웨어에서 실행하는 것입니다. 경제적 또는 물리적 제약이나 환경적 우려 때문에 하드웨어를 업그레이드할 수 없다면, 스택의 더 높은 계층을 살펴보기 시작해야 할 수도 있습니다.

하드웨어와 관련하여 가장 중요한 두 가지 선택은 멀티코어인지 여부와 32비트인지 64비트인지 여부입니다. 멀티코어를 사용할지 여부와 32비트를 사용할지 64비트를 사용할지에 따라 서로 다른 ERTS 빌드가 필요합니다.

스택의 두 번째 계층은 OS 수준입니다. ERTS는 대부분의 Windows 버전과 Linux, FreeBSD, Solaris, Mac OS X를 포함한 대부분의 POSIX "호환" 운영 체제에서 실행됩니다. 오늘날 ERTS 개발은 대부분 Linux와 OS X에서 이루어지며, 이 플랫폼들에서 최상의 성능을 기대할 수 있습니다. 하지만 Ericsson은 사내의 많은 프로젝트에서 Solaris를 사용해 왔으며, ERTS는 여러 해 동안 Solaris에 맞게 튜닝되어 왔습니다. 사용 사례에 따라서는 실제로 Solaris 시스템에서 최상의 성능을 얻을 수도 있습니다. OS 선택은 보통 성능 요구 사항에 따라 결정되지 않으며, 다른 요인들에 의해 제약을 받습니다. 임베디드 애플리케이션을 만든다면 Raspbian만 사용해야 할 수도 있고, 어떤 이유로 최종 사용자용 애플리케이션이나 클라이언트 애플리케이션을 만든다면 Windows를 사용해야 할 수도 있습니다. ERTS의 Windows 포트는 지금까지 최우선 순위로 다뤄지지 않았으며, 성능이나 유지 보수 관점에서 최선의 선택이 아닐 수 있습니다. 64비트 ERTS를 사용하려면 당연히 64비트 머신과 64비트 OS가 모두 필요합니다. 이 책에서는 OS별 문제를 많이 다루지 않으며, 대부분의 예제는 Linux에서 실행한다고 가정합니다.

스택의 세 번째 계층은 Erlang 런타임 시스템입니다. 여기서는 이것이 ERTS입니다. 이 계층과 네 번째 계층인 Erlang 가상 머신(BEAM)이 바로 이 책에서 다루는 내용입니다.

다섯 번째 계층인 OTP는 Erlang 표준 라이브러리를 제공합니다. OTP는 원래 "Open Telecom Platform"의 약자였으며, (전화 교환기와 같은) 견고한 애플리케이션을 구축하는 데 필요한 구성 요소(supervisor, gen_server, gen_tcp 등)를 제공하는 여러 Erlang 라이브러리를 가리켰습니다. 일찍부터 이 라이브러리들과 OTP의 의미는 ERTS와 함께 배포되는 다른 모든 표준 라이브러리와 뒤섞이게 되었습니다. 오늘날 대부분의 사람들은 ERTS와 Ericsson이 배포하는 모든 Erlang 라이브러리를 가리키는 이름으로 OTP를 Erlang과 함께 묶어 "Erlang/OTP"라고 부릅니다. 이러한 표준 라이브러리를 알고 언제 어떻게 사용해야 하는지 이해하면 애플리케이션의 성능을 크게 향상시킬 수 있습니다. 이 책에서는 표준 라이브러리와 OTP를 자세히 다루지 않습니다. 이러한 측면을 다루는 다른 책이 많이 있습니다.

Elixir 프로그램을 실행하는 경우, 여섯 번째 계층이 Elixir 환경과 Elixir 라이브러리를 제공합니다.

마지막으로, 일곱 번째 계층(Apps)은 여러분의 애플리케이션과 여러분이 사용하는 서드파티 라이브러리입니다. 애플리케이션은 하위 계층들이 제공하는 모든 기능을 사용할 수 있습니다. 하드웨어를 업그레이드하는 것을 제외하면, 아마도 이 계층이 애플리케이션의 성능을 가장 쉽게 개선할 수 있는 곳일 것입니다. Chapter 21에서는 애플리케이션을 프로파일링하고 최적화하는 데 도움이 되는 몇 가지 힌트와 도구를 소개합니다. Chapter 18에서는 애플리케이션이 크래시하는 원인을 찾는 방법과 애플리케이션의 버그를 찾는 방법을 살펴보겠습니다.

Erlang 언어 설계자들이 얻은 핵심 통찰 중 하나는 연중무휴 24시간 동작하는 시스템을 구축하려면 하드웨어 장애에 대처할 수 있어야 한다는 것이었습니다. 따라서 시스템을 최소 두 대의 물리 머신에 분산해야 합니다. 이를 위해 각 머신에서 노드를 시작한 다음 노드들을 서로 연결하면, 프로세스들이 마치 같은 노드에서 실행되는 것처럼 노드를 넘나들며 서로 통신할 수 있습니다. 분산에 대한 자세한 내용은 Chapter 14을 참조하십시오.

Erlang 컴파일러는 Erlang 소스 코드, 즉 .erl 파일을 BEAM 가상 머신 코드로 컴파일하는 역할을 합니다. 컴파일러 자체도 Erlang 애플리케이션으로, Erlang으로 작성되었으며 자기 자신에 의해 BEAM 코드로 컴파일됩니다. 배포되는 Erlang 기반 시스템(릴리스)에는 해당 시스템이 코드를 실행할 뿐만 아니라 컴파일도 할 수 있어야 하는지에 따라 컴파일러가 포함될 수도 있고 포함되지 않을 수도 있습니다.

런타임 시스템을 부트스트랩하기 위해 Erlang의 소스 분산본에는 컴파일러를 비롯하여 미리 컴파일된 여러 BEAM 파일이 bootstrap 및 erts/preloaded 디렉터리에 포함되어 있습니다.

컴파일러에 대한 자세한 내용은 Chapter 2를 참조하십시오.

BEAM은 Erlang 코드를 실행하는 데 사용되는 가상 머신입니다. JVM이 Java 코드를 실행하는 데 사용되는 것과 같습니다. BEAM 코드는 Erlang 노드의 컨텍스트 안에서 실행됩니다.

ERTS가 Erlang 런타임 시스템이라는 더 일반적인 개념의 한 구현인 것처럼, BEAM 역시 더 일반적인 Erlang 가상 머신 (EVM)의 한 구현입니다. 무엇이 EVM을 이루는지에 대한 정의는 없지만, BEAM에는 실제로 두 가지 수준의 명령어, 즉 일반 명령어(Generic Instructions)와 특정 명령어(Specific Instructions)가 있습니다. 범용 명령어 집합은 EVM의 청사진으로 볼 수 있습니다.

BEAM에 대한 자세한 설명은 Chapter 5 및 이어지는 장들에서 확인할 수 있습니다.

Erlang 프로세스는 기본적으로 OS 프로세스처럼 동작합니다. 각 프로세스는 자신만의 전용 메모리(메일박스, 힙, 스택)와 해당 프로세스에 대한 정보를 담은 프로세스 제어 블록(PCB)을 가집니다. Erlang 프로세스는 스레드와 다릅니다. 수정할 공유 메모리가 없고, 오직 메시지를 통해서만 통신할 수 있으며, 한 프로세스의 관점에서는 다른 프로세스가 같은 VM에서 실행되든 네트워크로 연결된 다른 노드에서 실행되든 차이가 거의 없습니다. Erlang 프로그램에는 잠금이나 보호 구역이 필요하지 않습니다.

모든 Erlang 코드는 프로세스의 컨텍스트 안에서 실행됩니다. 하나의 Erlang 노드에는 여러 프로세스가 있을 수 있으며, 이 프로세스들은 메시지 전달과 시그널을 통해 서로 통신합니다. Erlang 프로세스는 노드끼리 연결되어 있기만 하면 다른 Erlang 노드에 있는 프로세스와도 통신할 수 있습니다.

프로세스와 PCB에 대해 더 자세히 알아보려면 Chapter 3를 참조하십시오.

스케줄러는 실행할 Erlang 프로세스를 선택하는 역할을 합니다. 기본적으로 스케줄러는 두 개의 큐를 유지합니다. 하나는 실행할 준비가 된 프로세스들의 준비 큐이고, 다른 하나는 메시지 수신을 기다리는 프로세스들의 대기 큐입니다.

스케줄러는 준비 큐(ready queue)에서 첫 번째 프로세스를 골라 BEAM에 넘기고, BEAM은 이 프로세스를 타임 슬라이스(time slice) 하나 동안 실행합니다. BEAM은 타임 슬라이스를 다 쓰면 실행 중인 프로세스를 선점하고, 그 프로세스를 준비 큐의 맨 뒤로 되돌려 보냅니다. 타임 슬라이스를 다 쓰기 전에 프로세스가 receive에서 블로킹되면, 그 프로세스는 대신 대기 큐(waiting queue)로 옮겨집니다. 대기 큐에 있는 프로세스가 메시지를 받거나 타임아웃이 발생하면, 그 프로세스는 준비 큐로 옮겨집니다.

Erlang은 본질적으로 동시적입니다. 즉, 각 프로세스는 개념적으로 다른 모든 프로세스와 동시에 실행되지만, 실제로는 스케줄러가 한 번에 하나의 프로세스만 실행할 뿐입니다. 따라서 단일 코어 머신에서도, 그리고 기반 OS가 선점을 지원하지 않더라도, BEAM은 수십만 개의 동시 프로세스로 이루어진 동일한 Erlang 프로그램을 여전히 실행할 수 있습니다.

멀티코어 머신에서 Erlang은 자동으로 둘 이상의 스케줄러를 각각 별도의 OS 스레드에서 실행합니다. 보통 물리 코어당 하나씩 실행하며, 각 스케줄러는 자체 실행 큐를 가집니다. 한 스케줄러에 할 일이 떨어지면, 그 스케줄러는 다른 스케줄러들로부터 실행 준비가 된 프로세스 일부를 넘겨받을 수 있습니다. 이런 방식으로 Erlang은 프로그래머가 신경 쓸 필요 없이 진정한 병렬성을 달성합니다.

실제로는 프로세스 간에 우선순위가 있어 상황이 더 복잡하며, 대기 큐는 타이밍 휠로 구현되어 있습니다. 이 모든 내용과 그 이상의 사항은 Chapter 10에서 자세히 설명합니다.

Erlang은 동적 타입 언어이므로 런타임 시스템에는 각 데이터 객체의 타입을 추적할 방법이 필요합니다. 이는 태깅 방식으로 이루어집니다. 각 데이터 객체나 데이터 객체를 가리키는 포인터에는 해당 객체의 데이터 타입 정보를 담은 태그도 붙어 있습니다.

기본적으로 포인터의 일부 비트는 태그용으로 예약되어 있으며, VM은 태그의 비트 패턴을 보고 객체의 타입을 판별할 수 있습니다.

이 태그는 패턴 매칭, 타입 테스트, 기본 연산에 사용되며 가비지 컬렉터에서도 사용됩니다.

전체 태깅 방식은 Chapter 4에 설명되어 있습니다.

Erlang은 자동 메모리 관리를 사용하므로 프로그래머는 메모리 할당과 해제에 대해 신경 쓸 필요가 없습니다. 각 프로세스는 힙과 스택을 가지며, 둘 다 필요에 따라 커지거나 줄어들 수 있습니다. OS 스레드에서는 있을 수 있는 스택 크기 제한도 걱정할 필요가 없고, 스택을 위해 미리 할당된 주소 범위도 없습니다. 처음에는 프로세스의 스택과 힙이 모두 상당히 작기 때문에 수천 개, 심지어 수백만 개의 프로세스를 둘 수 있습니다.

프로세스의 힙 공간이 부족해지면 VM은 먼저 가비지 컬렉션을 통해 여유 힙 공간을 회수하려고 시도합니다. 그런 다음 가비지 컬렉터는 프로세스의 스택과 힙을 훑으면서 살아 있는 데이터를 새 힙으로 복사하고, 죽은 데이터는 모두 버립니다. 그래도 힙 공간이 충분하지 않으면 더 큰 새 힙이 할당되고, 살아 있는 데이터가 그곳으로 옮겨집니다.

참조 카운트 방식 바이너리의 처리를 포함하여, 현재의 세대별 복사 가비지 컬렉터에 대한 자세한 내용은 Chapter 11에서 확인할 수 있습니다.

erl로 Erlang 노드를 시작하면 명령 프롬프트가 나타납니다. 이것은 Erlang 읽기-평가-출력 루프(REPL) 또는 명령줄 인터페이스(CLI), 혹은 간단히 Erlang 셸입니다.

셸에서 Erlang 표현식을 입력하고 바로 실행할 수 있습니다. 이 경우 코드는 BEAM 코드로 컴파일되어 BEAM에서 실행되는 것이 아닙니다. 대신 코드는 Erlang 인터프리터가 파싱하고 해석합니다. 일반적으로 인터프리트된 코드는 컴파일된 코드와 똑같이 동작하지만 몇 가지 미묘한 차이가 있습니다. 특히 인터프리트된 코드는 더 느립니다. 이러한 차이점을 비롯해 셸의 다른 모든 측면은 Chapter 17에서 설명합니다.

Erlang on Xen (https://github.com/cloudozer/ling)은 중간에 OS 계층 없이 얇은 Xen 클라이언트만 둔 채 서버 하드웨어에서 직접 실행되는 Erlang 구현체입니다.

Erlang on Xen의 가상 머신인 Ling은 BEAM과 바이너리 수준에서 거의 100% 호환됩니다. Figure 4에서 Erlang Solution Stack의 Erlang on Xen 구현이 ERTS 스택과 어떻게 다른지 확인할 수 있습니다. 여기서 주목할 점은 Erlang on Xen 스택에는 운영 체제가 없다는 것입니다.

Ling은 BEAM의 범용 명령어 집합을 구현하므로, OTP 계층의 BEAM 컴파일러를 재사용하여 Erlang을 Ling으로 컴파일할 수 있습니다.

Erjang (https://github.com/trifork/erjang)은 JVM 위에서 실행되는 Erlang 구현체입니다. .beam 파일을 로드하여 코드를 Java .class 파일로 다시 컴파일합니다. Erjang은 (일반적인) BEAM과 바이너리 수준에서 거의 100% 호환됩니다.

Figure 5에서 Erlang 솔루션 스택의 Erjang 구현이 ERTS 스택과 어떻게 다른지 확인할 수 있습니다. 여기서 주목할 점은 JVM이 BEAM을 대신하여 가상 머신 역할을 한다는 것과, Erjang이 ERTS의 서비스를 JVM 위에서 Java로 구현하여 제공한다는 것입니다.

이제 ERTS의 주요 구성 요소 전반과 필요한 용어를 기본적으로 이해했으므로, 각 구성 요소를 자세히 살펴볼 수 있습니다. 특정 구성 요소를 빨리 이해하고 싶다면 해당 장으로 바로 건너뛰어도 됩니다. 또는 특정 문제의 해결책을 정말 빨리 찾고 싶다면 Part II의 알맞은 장으로 건너뛰어 시스템을 튜닝하거나 조정하거나 디버깅하는 여러 방법을 시도해 볼 수 있습니다.

컴파일은 토큰화(또는 스캐닝)와 전처리로 시작합니다. 전처리기 epp는 파일을 읽고 토크나이저 erl_scan을 호출하여 텍스트를 문자 단위가 아닌 개별 토큰 시퀀스로 풀어내며, 이 과정에서 공백과 주석은 버립니다. 그런 다음 매크로 정의와 조건부 컴파일 지시문을 처리하고, 매크로가 사용된 부분을 치환합니다.

전처리기는 include 문을 발견하면 지정된 include 파일을 읽어 토큰화하고, 그 결과로 얻은 토큰 시퀀스를 include 문 대신 삽입한 뒤, 이것 역시 처리합니다. 따라서 파일들이 서로를 재귀적으로 include할 수 있습니다. 전처리기는 한 파일에서 다른 파일로 전환할 때 앞의 예제에서 본 것처럼 -file 어노테이션을 삽입하여, 이후 패스에서 특정 코드 조각이 어디에서 왔는지 알 수 있도록 합니다:

world.hrl과 같은 include 파일이 처리될 때 실제로는 아무 코드도 삽입되지 않을 수 있다는 점에 유의하십시오. include 파일에는 매크로 정의와 전처리기 조건문만 들어 있는 경우가 많기 때문입니다. 남는 것은 “we are now at line 1 of the header file”, “we are now back at line 4 in the original source file” 두 주석뿐입니다.

이 모든 것은 epp가 (C/C++ 전처리기 cpp와 마찬가지로) 토큰 수준에서 동작한다는 뜻이므로, (예를 들어 m4와 같은) 순수한 문자열 치환 처리기가 아니라는 점에 유의하십시오. Erlang 매크로로 임의의 문법을 직접 정의할 수는 없습니다. 매크로는 주변 문자와 분리된 별개의 토큰으로 확장되므로, 매크로와 문자를 이어 붙여 하나의 토큰으로 만들 수 없습니다:

이는 다음과 같이 확장됩니다

그리고 다음은 아닙니다

한편 매크로 확장은 실제 파싱 전에 토큰 스트림에서 이루어지므로, 매크로의 우변에 반드시 유효한 Erlang 텀이 올 필요는 없습니다. 최종적으로 유효한 텀이 되도록 사용하기만 하면 됩니다. 예를 들면 다음과 같습니다.

이는 다음 토큰 시퀀스로 확장됩니다.

난독화된 Erlang 코드 대회에서 우승하는 것 말고는 이 기능을 실제로 쓸 일이 거의 없습니다. 기억해야 할 핵심은 Erlang 전처리기로 Erlang과 다른 구문을 가진 언어를 정의하기는 사실상 불가능하다는 점입니다.

파서 erl_parse는 전처리기로부터 최종 토큰 시퀀스를 받아 Erlang 문법에 맞는지 검사하고, 프로그램을 순차적인 텍스트가 아닌 데이터 구조로 표현하는 추상 구문 트리 또는 AST(http://www.erlang.org/doc/apps/erts/absform.html 참고)를 생성합니다.

파스 트랜스폼은 AST를 대상으로 동작하는 함수입니다. 컴파일러는 초기 토큰화, 전처리, 파싱을 마친 뒤 그때까지 오류가 없었다면, 파스 트랜스폼 함수가 선언된 경우 그 함수를 호출합니다. 이때 컴파일러는 현재 AST를 함수에 넘기고, 수정된 AST를 돌려받을 것으로 기대합니다.

즉, 입력이 여전히 Erlang 파서에서 받아들여져야 하므로 Erlang 문법을 근본적으로 바꿀 수는 없지만, 코드를 원하는 대로 수정하여 의미는 바꿀 수 있다는 뜻입니다.

파스 트랜스폼은 이를 사용할 모듈 안에서 다음과 같이 선언합니다:

그러면 컴파일러는 추가 패스로 my_pt:parse_transform(Forms, Options)를 호출하려고 시도합니다. 한 모듈에서 여러 파스 트랜스폼을 사용할 수 있으며, 이들은 단순히 순서대로 실행됩니다.

파스 트랜스폼은 Mnesia(QLC 구문용), EUnit, Merl 등의 라이브러리에서 사용됩니다. Section 2.5에서는 파스 트랜스폼을 직접 구현하는 방법을 전체 예제로 보여 드리겠습니다.

“linter”라는 텀은 원래 컴파일러에 덧붙여 쓰는 도구를 뜻했습니다. 이 도구는 의류 건조기의 보풀 필터(lint filter)처럼 스타일상의 오류와 안티패턴 등 컴파일러 자체가 검사하지 않는 여러 사항을 검사했습니다(당시 컴파일러는 사용할 수 있는 메모리가 매우 적었고 속도에 중점을 두었기 때문입니다). 그러나 컴퓨터가 빨라지면서 린터는 가끔씩만이 아니라 항상 실행하고 싶은 패스로서 컴파일러 안으로 옮겨졌습니다.

Erlang 컴파일러에서 린터 erl_lint는 파싱과 변환이 끝난 뒤 소스 코드 검사의 대부분을 수행하는 단계입니다. (즉, 파스 트랜스폼은 린터가 받아들이는 AST만 반환할 수 있습니다.)

린터는 정의되지 않은 변수나 함수 같은 오류를 검사할 뿐만 아니라, "export_all flag enabled"처럼 올바르지만 의심스러운 코드에 대해서도 경고를 생성합니다.

모듈의 디버깅을 활성화하려면 해당 모듈을 “debug compile” 해야 합니다. 즉, 컴파일러에 debug_info 옵션을 전달해야 합니다. 그러면 추상 구문 트리는 “Save AST” 패스에서 저장되어 컴파일이 끝날 때까지 보존되며, 컴파일이 끝나면 브레이크포인트 설정, 단일 스텝 실행 등을 위해 .beam 파일에 포함됩니다. 이때 코드는 컴파일된 상태가 아니라 인터프리트되어 실행됩니다.

코드는 최적화가 적용되기 전에 저장된다는 점에 유의해야 합니다. 따라서 컴파일러의 최적화 패스에 버그가 있는 경우, 디버거에서 인터프리트된 코드를 실행하면 다르게 동작합니다. 컴파일러 최적화를 직접 구현하고 있다면 이 점 때문에 크게 곤란을 겪을 수 있습니다.

확장 단계에서는 레코드와 같은 소스 수준의 Erlang 구성 요소가 더 낮은 수준의 Erlang 구성 요소로 확장됩니다. 이 단계에서는 컴파일러 지시문을 제거하고, 레코드 구문을 튜플에 대한 연산으로 바꾸고, 임포트한 함수의 사용을 명시적인 원격 호출로 확장하며, 내장 함수 module_info/{1,2}를 코드에 추가합니다.

Core Erlang은 컴파일러 최적화에 적합한 엄격한(strict) 함수형 언어입니다. Core Erlang은 같은 연산을 표현하는 방법의 수를 줄여 코드 변환을 더 쉽게 만듭니다. 이를 위한 방법 중 하나는 let 및 letrec 식을 도입하여 스코프를 더 명시적으로 만드는 것입니다. 컴파일러는 코어 수준에서 여러 차례의 패스를 수행합니다.

Core Erlang은 ERTS에서 실행하려는 언어의 좋은 타깃이 될 수 있습니다. Core Erlang은 거의 바뀌지 않으며, Erlang의 모든 측면을 깔끔한 형태로 담고 있습니다. BEAM 명령어 집합을 직접 타깃으로 삼으면 훨씬 더 많은 세부 사항을 다루어야 하며, 그 명령어 집합은 보통 ERTS의 메이저 릴리스마다 조금씩 바뀝니다. 반면 Erlang을 직접 타깃으로 삼으면 기술할 수 있는 내용이 더 제한되며, Core Erlang이 더 깔끔한 언어이므로 더 많은 세부 사항을 다루어야 할 수도 있습니다.

다만 일반 Erlang을 대상으로 하면 생성한 코드가 올바르게 동작하는지 컴파일 시점에 더 많이 검사받을 수 있다는 점에 유의하십시오. Core Erlang을 직접 생성하면 Erlang 컴파일러가 이전에 한 번도 마주친 적 없는 코너 케이스를 발견하게 될 수도 있습니다. 따라서 올바른 코드를 생성해야 할 책임이 여러분에게 더 크게 주어집니다.

Erlang 파일을 core로 컴파일하려면 to_core 옵션을 지정하면 됩니다. 이렇게 하면 생성된 Core Erlang 프로그램이 확장자가 .core인 파일로 출력됩니다. .core 파일에서 Core Erlang 프로그램을 컴파일하려면 컴파일러에 from_core 옵션을 지정하면 됩니다.

.core 파일은 사람이 읽을 수 있는 core 형식으로 작성된 텍스트 파일이라는 점에 유의하십시오. core 프로그램을 Erlang 텀으로 얻으려면 컴파일할 때 binary 옵션을 추가하면 됩니다.

Kernel Erlang은 Core Erlang을 평탄화한(flat) 버전으로, 몇 가지 차이점이 있습니다. 예를 들어, 각 변수는 고유하며 스코프는 함수 전체입니다. 패턴 매칭은 더 원시적인 연산으로 컴파일됩니다. 커널 표현에는 잘 정의된 파일 형식이 없으며, 안정적일 것이라고 기대해서는 안 됩니다.

일반적인 컴파일의 마지막 단계는 외부 BEAM 어셈블리 코드 형식으로, Erlang 텀으로 표현된 개별 BEAM 명령어의 시퀀스입니다. 데드 코드 제거와 핍홀 최적화 같은 일부 저수준 최적화가 이 단계에서 수행됩니다.

BEAM 코드는 Chapter 7 및 Appendix B에서 자세히 설명합니다

BEAM 어셈블리 코드는 최종적으로 바이너리 전송 형식으로 패킹되며, 이 형식은 .beam 파일에 기록하거나, 네트워크를 통해 전송하거나, code:load_binary/3을 통해 메모리에 직접 로드할 수 있습니다. 자세한 내용은 Chapter 6]를 참조하십시오.

Leex는 Erlang 렉서 생성기입니다. 렉서 생성기는 정의 파일 xrl에서 DFA의 기술을 받아, 그 DFA가 기술하는 토큰을 매칭하는 Erlang 프로그램을 생성합니다.

토크나이저용 DFA 정의를 작성하는 방법의 세부 사항은 이 책의 범위를 벗어납니다. 자세한 설명은 "Dragon book"([DragonBook])을 추천합니다. 그 밖의 좋은 자료로는 leex에 영감을 준 렉서 프로그램인 flex의 man 및 info 항목과 leex 문서 자체가 있습니다. info와 flex가 설치되어 있다면 다음과 같이 입력하여 전체 매뉴얼을 읽을 수 있습니다:

온라인 Erlang 문서에는 leex 매뉴얼도 있습니다(yecc.html 참조).

렉서 생성기를 사용하면 JSON 토큰을 인식하는 Erlang 프로그램을 만들 수 있습니다. JSON 정의 http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf 를 살펴보면 처리해야 할 토큰이 몇 가지뿐이라는 것을 알 수 있습니다.

Leex 컴파일러를 사용하면 이 DFA를 Erlang 코드로 컴파일할 수 있으며, dfa_graph 옵션을 지정하면 Graphviz 등으로 볼 수 있는 dot 파일도 함께 생성할 수 있습니다.

예를 들어 dotty를 사용하면 DFA 그래프(Figure 8)를 볼 수 있습니다:

예제 JSON 파일(test.json)로 우리 토크나이저를 시험해 볼 수 있습니다.

먼저 토크나이저를 컴파일한 다음, 파일을 읽어 문자열로 변환해야 합니다. 마지막으로 leex가 생성하는 string/1 함수를 사용하여 테스트 파일을 토큰화할 수 있습니다.

셸 함수 f/1은 셸이 변수 바인딩을 잊도록 합니다. 이 함수는 변수를 바인딩하는 명령을 여러 번 실행해 보고 싶을 때 유용합니다. 예를 들어 렉서를 작성하면서 코드를 고칠 때마다 실행해 보고 싶은 경우가 그렇습니다. 셸 명령은 뒤의 장에서 자세히 살펴보겠습니다.

JSON 토크나이저를 갖추었으니 이제 파서 생성기 Yecc를 사용하여 json 파서를 작성할 수 있습니다.

Yecc는 Erlang용 파서 생성기입니다. 이 이름은 C의 대표적인 파서 생성기인 Yacc(Yet Another Compiler Compiler, 또 하나의 컴파일러 컴파일러)에서 유래했습니다. 이에 해당하는 현대의 오픈 소스 도구는 Bison이며, 흔히 Flex와 함께 사용됩니다.

이제 JSON 텀을 위한 렉서가 있으므로 yecc를 사용하여 파서를 작성할 수 있습니다.

그런 다음 yecc를 사용하여 파서를 구현하는 Erlang 프로그램을 생성하고, 토크나이저가 생성한 토큰을 인수로 전달하여 제공된 parse/1 함수를 호출할 수 있습니다.

Leex와 Yecc 도구는 직접 만든 완전한 언어를 Erlang 가상 머신용으로 컴파일하려 할 때 유용합니다. 이 도구들을 Syntax tools, 특히 Merl과 함께 사용하면 Erlang 추상 구문 트리를 조작하여 Erlang 코드를 생성하거나 Erlang 코드의 동작을 바꿀 수 있습니다.

바로 본론으로 들어가서 실행 중인 시스템에 어떤 프로세스가 있는지 살펴봅시다. 가장 쉬운 방법은 Erlang 셸을 시작하고 셸 명령 i()를 실행하는 것입니다. Elixir에서는 shell_default 모듈의 함수를 :shell_default.i로 호출할 수 있습니다.

i/0 함수는 시스템에 있는 모든 프로세스의 목록을 출력합니다. 각 프로세스마다 두 줄의 정보가 표시됩니다. 출력의 처음 두 줄은 각 정보가 무엇을 의미하는지 알려 주는 헤더입니다. 보시다시피 프로세스 ID(Pid)와 프로세스 이름(있는 경우)뿐 아니라, 프로세스가 시작된 코드와 현재 실행 중인 코드에 관한 정보도 얻을 수 있습니다. 또한 힙과 스택의 크기, 그리고 프로세스의 리덕션 수와 메시지 수에 관한 정보도 얻을 수 있습니다. 이 장의 나머지 부분에서는 스택, 힙, 리덕션, 메시지가 무엇인지 자세히 알아보겠습니다. 지금은 힙 크기의 수치가 크면 프로세스가 메모리를 많이 사용하고 있고, 리덕션 수치가 크면 프로세스가 많은 코드를 실행했다고 간단히 가정해도 됩니다.

i/3 함수를 사용하면 프로세스를 더 자세히 살펴볼 수 있습니다. code_server 프로세스를 살펴봅시다. 앞의 목록에서 code_server의 프로세스 식별자(pid)가 <0.36.0>임을 확인할 수 있습니다. pid의 세 숫자를 인자로 i/3을 호출하면 다음 정보를 얻을 수 있습니다:

이 호출로 많은 정보를 얻었으며, 이 장의 나머지 부분에서는 이 항목들 대부분이 무엇을 의미하는지 자세히 알아보겠습니다. 첫 번째 줄은 이 프로세스에 code_server라는 이름이 부여되었음을 알려 줍니다. 다음으로 프로세스가 현재 실행 중이거나 일시 중단된 함수(current_function)와 프로세스가 실행을 시작한 함수의 이름(initial_call)을 확인할 수 있습니다.

또한 프로세스가 메시지를 기다리며 일시 중단되어 있고({status,waiting}) 메일박스에 메시지가 없다는 것({message_queue_len,0}, {messages,[]})도 확인할 수 있습니다. 메시지 전달이 어떻게 동작하는지는 이 장의 뒷부분에서 더 자세히 살펴보겠습니다.

priority, suspending, reductions, links, trap_exit, error_handler, group_leader 필드는 프로세스 실행, 오류 처리, IO를 제어합니다. 이에 대해서는 Observer를 소개할 때 좀 더 자세히 살펴보겠습니다.

마지막 몇 개의 필드(dictionary, total_heap_size, heap_size, stack_size, garbage_collection)는 프로세스의 메모리 사용량에 관한 정보를 제공합니다. 프로세스 메모리 영역은 Chapter 11 장에서 자세히 살펴보겠습니다.

프로세스 정보를 얻는 또 다른 방법으로, 이보다 훨씬 더 침습적인 방법은 BREAK 메뉴에서 제공하는 프로세스 정보를 사용하는 것입니다: Ctrl+c p [enter]. BREAK 상태에 있는 동안에는 노드 전체가 멈춘다는 점에 유의하십시오.

셸 함수는 프로세스에 관한 정보를 출력하기만 하지만, 실제로는 이 정보를 데이터로 얻을 수 있으므로 프로세스를 검사하는 도구를 직접 작성할 수 있습니다. erlang:processes/0로 모든 프로세스의 목록을 얻을 수 있고, erlang:process_info/1로 특정 프로세스에 관한 정보를 얻을 수 있습니다. 또한 whereis/1 함수를 사용하여 이름으로 pid를 얻을 수도 있습니다:

프로세스 정보를 데이터로 얻으면 그 데이터를 원하는 대로 분석하거나 정렬하는 코드를 작성할 수 있습니다. 시스템의 모든 프로세스를 가져온 다음(erlang:processes/0 사용) 각 프로세스의 힙 크기 정보를 얻으면(erlang:process_info(P, total_heap_size) 사용), pid와 힙 크기로 이루어진 리스트를 만들어 힙 크기 기준으로 정렬할 수 있습니다:

많은 프로세스의 힙 크기가 233워드라는 것을 볼 수 있을 텐데, 이는 233워드가 프로세스의 기본 시작 힙 크기이기 때문입니다.

process_info/2로 얻을 수 있는 정보에 대한 전체 설명은 erlang 모듈의 문서를 참고하십시오: https://erlang.org/doc/apps/erts/erlang.html#process_info/2 process_info/1 함수는 프로세스에 대해 얻을 수 있는 전체 정보 중 일부만 반환하며, 추가 정보는 process_info/2 함수로 가져올 수 있다는 점에 주목하십시오. 예를 들어, 위의 code_server 프로세스에서 backtrace를 추출하려면 다음을 실행하면 됩니다:

위 바이너리 끝에 있는 점 세 개가 보이십니까? 이는 출력이 잘렸다는 뜻입니다. 전체 값을 보는 유용한 방법은 위의 함수 호출을 rp/1 함수로 감싸는 것입니다:

다른 방법으로, 다음과 같이 io:put_chars/1 함수를 사용할 수도 있습니다:

출력이 장황하여 4> 명령과 6> 명령의 출력은 여기에 싣지 않았지만, 위 명령을 Erlang 셸에서 직접 실행해 보십시오.

프로세스를 살펴보는 세 번째 방법은 Observer를 사용하는 것입니다. Observer는 Erlang 런타임 시스템을 살펴볼 수 있는 폭넓은 그래픽 인터페이스입니다. 이 책 전반에 걸쳐 Observer를 사용하여 시스템의 여러 측면을 살펴보겠습니다.

지금은 다음과 같이 Erlang 셸에서 Observer를 시작하기만 하겠습니다:

또는 Elixir 셸에서 :observer.start로 실행할 수도 있습니다. 실행 중인 시스템을 디버깅할 때는 Observer 실행만을 위한 임시 Erlang 노드를 띄우고, 검사 대상 노드가 옵저버 노드를 볼 수 없도록 -hidden 플래그를 사용하는 것이 좋습니다.

Observer를 시작하면 다음 스크린샷과 같이 시스템 개요가 표시됩니다.

이 정보 중 일부는 이 장의 뒷부분과 다음 장에서 자세히 살펴보겠습니다. 지금은 Observer를 사용하여 실행 중인 프로세스를 살펴보기만 하겠습니다. 먼저 실행 중인 시스템의 슈퍼비전 트리를 보여 주는 Applications 탭을 살펴보겠습니다:

여기서는 프로세스들이 어떻게 링크되어 있는지 그래픽으로 볼 수 있습니다. 이는 시스템이 어떻게 구성되어 있는지 한눈에 파악할 수 있는 아주 좋은 방법입니다. 또한 프로세스들이 링크를 통해 서로 연결된 채 공간에 떠 있는 고립된 개체라는 느낌도 잘 받을 수 있습니다.

프로세스에 관한 실질적으로 유용한 정보를 얻기 위해 Processes 탭으로 전환합니다:

이 화면에서는 셸에서 i/0을 실행했을 때와 기본적으로 같은 정보를 얻을 수 있습니다. pid, 등록된 이름, 리덕션 수, 메모리 사용량, 메시지 수, 현재 함수를 볼 수 있습니다.

또한 코드 서버처럼 프로세스의 행을 더블 클릭하면 해당 프로세스를 자세히 살펴볼 수 있으며, process_info/2로 얻을 수 있는 것과 같은 종류의 정보를 확인할 수 있습니다:

이 모든 정보가 무엇을 의미하는지 지금 당장 살펴보지는 않겠지만, 계속 읽어 나가다 보면 결국 모든 것이 밝혀질 것입니다.

이제 프로세스가 무엇인지 기본적으로 이해했고 시스템에서 프로세스를 찾아 검사할 수 있는 도구도 몇 가지 갖추었으니, 프로세스가 어떻게 구현되는지 더 깊이 살펴볼 준비가 되었습니다.

멀티코어 시스템이 도입되고 Erlang 구현이 둘 이상의 스케줄러가 실행 중인 프로세스를 병렬로 처리하도록 확장되자, 수신자의 main lock을 획득하지 않고 다른 프로세스의 힙에 직접 쓰는 것은 더 이상 안전하지 않게 되었습니다. 이때 m-bufs라는 개념이 도입되었습니다(힙 프래그먼트라고도 합니다). m-buf는 프로세스 힙 바깥에 있는 메모리 영역으로, 다른 프로세스가 안전하게 데이터를 쓸 수 있는 곳입니다. 송신 프로세스가 락을 획득하지 못하면 대신 m-buf에 데이터를 씁니다. 메시지의 모든 데이터가 m-buf에 복사되면, 메시지는 메일박스를 통해 프로세스에 연결됩니다. 이 연결 작업(erl_message.h의 LINK_MESSAGE)은 메시지를 수신자의 메시지 큐 끝에 추가합니다.

그러면 가비지 컬렉터가 메시지를 프로세스의 힙으로 복사합니다. GC의 부담을 줄이기 위해 메일박스는 두 개의 리스트로 나뉘는데, 하나는 이미 확인한 메시지를 담고 다른 하나는 새 메시지를 담습니다. 새 메시지는 살아남는다는 것을 알고 있으므로(아직 메일박스에 있으므로) GC는 새 메시지를 살펴볼 필요가 없으며, 이렇게 하면 복사 작업의 일부를 피할 수 있습니다.

이제 프로세스를 네 개의 메모리 영역으로 보던 그림을 다시 한번 수정할 수 있습니다. 이제 프로세스는 Figure 14에 나타낸 것처럼 다섯 개의 메모리 영역(두 개의 메일박스)과 가변적인 수의 힙 프래그먼트(m-bufs)로 구성됩니다:

각 메일박스는 길이 하나와 포인터 두 개로 구성되며, 이 값들은 내부 큐의 경우 msg.len, msg.first, msg.last 필드에, 외부 입력 큐의 경우 msg_inq.len, msg_inq.first, msg_inq.last 필드에 저장됩니다. 또한 선택적 수신(selective receive)을 구현하기 위해 다음에 확인할 메시지를 가리키는 포인터(msg.save)도 있습니다.

지금은 분산의 경우는 무시하겠습니다. 즉, Erlang 노드 사이에서 전송되는 메시지는 고려하지 않겠습니다. 두 프로세스 P1과 P2가 있다고 가정해 보겠습니다. Figure 15에 나타난 것처럼, 프로세스 P1이 프로세스 P2에게 메시지(Msg)를 보내려고 합니다:

그러면 프로세스 P1은 다음 단계를 수행합니다:

프로세스 P2가 일시 중단된 상태이고, 다른 어떤 프로세스도 P2에 메시지를 보내려 하지 않으며, 힙에 공간이 있고, 할당 전략이 on_heap이면, 메시지는 Figure 16에서와 같이 곧바로 힙에 놓입니다:

P1이 P2의 main lock을 얻을 수 없거나, P2의 힙에 공간이 충분하지 않고 할당 전략이 on_heap이면 메시지는 Figure 17에서와 같이 m-buf에 들어가지만 내부 메일박스에서 링크됩니다:

GC가 끝나면 메시지는 힙으로 옮겨집니다.

할당 전략이 off_heap이면 메시지는 Figure 18에서처럼 m-buf에 들어가고 외부 메일박스에서 링크됩니다:

GC 이후에도 메시지는 여전히 m-buf에 남아 있습니다. 메시지가 수신되어 힙의 다른 객체나 스택에서 도달 가능해진 뒤에야 비로소 GC 중에 메시지가 프로세스 힙으로 복사됩니다.

Erlang은 선택적 수신(selective receive)을 지원합니다. 즉, 일치하지 않는 메시지를 메일박스에 남겨 두었다가 나중의 receive에서 처리할 수 있습니다. 또한 일치하는 메시지가 없으면 프로세스는 메일박스에 메시지가 남아 있는 상태로 일시 중단될 수 있습니다. msg.save 필드에는 다음에 살펴볼 메시지를 가리키는 포인터에 대한 포인터가 들어 있습니다.

이후 장에서 m-bufs의 세부 사항과 가비지 컬렉터가 메일박스를 처리하는 방식을 다룰 것입니다. 또한 BEAM에서 receive가 구현되는 방식의 세부 사항도 이후 장에서 살펴볼 것입니다.

Erlang 19에서 새로 도입된 message_queue_data 플래그를 사용하면 메모리와 실행 시간을 새로운 방식으로 맞바꿀 수 있습니다. 수신 프로세스가 과부하 상태이면서 main lock을 계속 잡고 있다면, 송신 프로세스가 메시지를 m-buf에 빠르게 넣어 둘 수 있도록 off_heap 할당을 사용하는 것이 좋은 전략일 수 있습니다.

두 프로세스의 생산자-소비자 관계가 잘 균형 잡혀 있어 프로세스 락을 두고 실질적인 경합이 일어나지 않는다면, 수신자의 힙에 직접 할당하는 편이 더 빠르고 메모리도 덜 사용합니다.

수신자에게 메시지가 밀려 처리할 수 있는 것보다 더 많은 메시지를 받고 있다면, 메시지가 힙으로 복사되고 old 힙으로 옮겨지면서 실제로는 메모리를 더 많이 사용하기 시작할 수도 있습니다. 아직 확인하지 않은 메시지는 살아 있는 것으로 간주되므로, 힙이 커져야 하고 더 많은 메모리를 사용하게 됩니다.

시스템에 가장 적합한 할당 전략을 알아내려면 벤치마크를 수행하고 동작을 측정해야 합니다. 가장 먼저 해 볼 수 있는 가장 쉬운 테스트는 아마도 시스템 시작 시 기본 할당 전략을 변경하는 것입니다. ERTS 플래그 +hmqd는 기본 전략을 off_heap 또는 on_heap 중 하나로 설정합니다. 이 플래그 없이 Erlang을 시작하면 기본값은 on_heap입니다. Erlang이 +hmqd off_heap으로 시작되도록 벤치마크를 구성하면, 모든 프로세스가 오프 힙 할당을 사용할 때 시스템이 더 잘 동작하는지 아니면 더 나쁘게 동작하는지 테스트할 수 있습니다. 그런 다음 병목이 되는 프로세스를 찾아 해당 프로세스에 대해서만 할당 전략을 바꾸어 테스트해 볼 수 있습니다.

처음 두 비트는 기본 태그라고 하며, 다음과 같이 사용됩니다:

Immediate(태그 11)는 작은 정수처럼 그 자체로 완결된 워드입니다. 추가 워드가 필요하지 않습니다. Boxed 태그 10은 리스트를 제외하고 힙에 있는 객체를 가리키는 포인터에 사용됩니다.

헤더 태그 00은 힙에서 헤더 워드에만 사용되며, 이에 대해서는 Section 4.5에서 설명하겠습니다. 힙의 모든 객체는 정수 개의 머신 워드를 차지하며, 일반적으로 헤더 워드로 시작합니다. 스택에서는 대신 00 태그가 반환 주소, 즉 연속 포인터를 나타냅니다 — 이는 실용적인 선택입니다. 반환 주소는 어차피 항상 워드 단위로 정렬되므로 이러한 포인터에는 태깅/언태깅을 전혀 할 필요가 없습니다. 이는 00을 즉시값, 리스트 또는 박스형 값에 사용하는 것보다 더 나은 절충안입니다.

별도의 List 태그(01)는 리스트가 매우 빈번하게 사용되기 때문에 도입된 최적화입니다. 이 덕분에 각 cons 셀을 힙에 헤더 워드 없이 저장할 수 있으므로, 헤더 워드를 둘 때 리스트에 필요한 공간의 1/3을 절약할 수 있습니다. 이는 [Lists]와 [Strings]에서 살펴보겠습니다.

Immediate 태그는 다음과 같이 더 세분됩니다.

Pid와 포트는 즉시값이므로 효율적으로 동등 비교를 할 수 있습니다. 물론 실제로는 참조에 불과하며, pid는 프로세스 식별자로서 프로세스를 가리킵니다. 해당 프로세스는 어떤 프로세스의 힙에도 존재하지 않으며, PCB에 의해 관리됩니다. 포트도 거의 같은 방식으로 동작합니다.

PID 즉시값(immediate)은 하나의 머신 워드에 압축되어 들어갑니다. 최하위 두 비트는 기본 태그 11이고, 그다음 두 비트는 서브타입 00이며, 나머지 상위 비트에는 PID 값이 담깁니다. 32비트 시스템에서는 이 28비트가 15비트 프로세스 인덱스(프로세스 테이블 내 오프셋), 13비트 시리얼(재사용된 인덱스를 구별하기 위한 값), 그리고 작은 크리에이션(creation) 필드로 다시 나뉩니다. 셸에서 PID를 출력하면 <Node.Index.Serial> 형태로 표시되며, 여기서 creation 값(노드 부분)은 재시작 전후의 PID를 구별해 줍니다. 포트도 같은 레이아웃(서브타입 01)을 사용하며, 상위 비트를 포트 번호와 크리에이션으로 나눕니다. 참조 전체가 한 워드 안에 들어 있으므로, PID와 포트에 대한 동등(및 비동등) 검사는 단 한 번의 정수 비교로 귀결됩니다.

ERTS에는 두 가지 유형의 정수가 있습니다. 작은 정수와 bignum입니다. 작은 정수는 머신 워드 하나에서 태그 비트 4개를 뺀 크기에 들어갑니다. 즉, 32비트 시스템에서는 28비트, 64비트 시스템에서는 60비트에 들어갑니다. 반면 bignum은 필요한 만큼 커질 수 있으며(힙 공간에 의해서만 제한됨), 박스형 객체로서 힙에 저장됩니다([Boxed Terms] 참조).

작은 정수의 태그 비트 네 개를 모두 1로 두면, 에뮬레이터는 정수 산술 연산을 수행할 때 두 인자가 모두 즉시값(immediate)인지 효율적으로 검사할 수 있습니다. (is_both_small(x,y)는 (x & y & 1111) == 1111로 정의됩니다.)

Immediate 2 태그는 다음과 같이 더 세분됩니다:

아톰은 아톰 테이블 내의 인덱스와 아톰 태그로 구성됩니다. 두 아톰 즉시값은 즉시값 표현만 비교하여 동등성을 판별할 수 있습니다.

아톰 테이블에서 아톰은 다음과 같은 C 구조체로 저장됩니다:

len 필드와 ord0 필드 덕분에 두 아톰이 같은 네 글자로 시작하지 않는 한 두 아톰의 순서를 효율적으로 비교할 수 있습니다.

Catch 즉시값은 스택에서만 사용됩니다. 이 값에는 예외가 발생한 뒤 실행을 이어 갈 코드 내 지점을 가리키는 간접 포인터가 들어 있습니다. 이에 대한 자세한 내용은 Chapter 8에서 다룹니다.

Nil 태그는 Erlang에서 []로 표기하고 C 코드에서는 NIL이라고 부르는 빈 리스트에 사용됩니다. 워드의 나머지 비트는 모두 1로 채워집니다.

IO 리스트는 바이너리, 중첩 리스트, 문자열, 정수를 평탄화하지 않고 이어 붙일 수 있게 하여 Erlang 문자열을 확장합니다. 각 요소는 바이너리 청크이거나 리스트 노드이며, 드라이버는 최소한의 복사로 이들을 순서대로 출력합니다.

튜플(ERTS 코드 베이스에서는 ARITYVAL이라고 부릅니다)은 태그와 요소 개수를 담은 헤더와 함께 단순하게 저장되며, 튜플 요소(있는 경우)는 그 뒤에 이어지는 워드들에 저장됩니다. 예를 들어, {$h, $e, $l, $l, $o}` 같은 5-튜플은 메모리에서 다음과 같은 모습입니다 (Figure 22)

이는 빈 튜플 {}가 힙에서 모든 비트가 0인 단일 워드(arity 0, 서브태그 0000, 기본 태그 00)로 표현된다는 뜻임에 유의하십시오. 그러나 이 방식에는 힙에 있는 해당 워드를 가리키는 박스 포인터도 필요하므로, 즉시값이어서 추가 힙 워드 없이도 레지스터에 보관하거나 리스트의 꼬리로 저장하는 등으로 사용할 수 있는 NIL만큼 저렴하지는 않습니다.

바이너리는 바이트로 이루어진 불변 배열입니다. 내부적으로 바이너리의 표현 방식에는 네 가지 유형이 있습니다. 힙 바이너리와 refc 바이너리라는 두 유형은 바이너리 데이터를 담고 있습니다. 나머지 두 유형인 서브 바이너리와 매치 컨텍스트(BINARY_AGGREGATE 태그)는 앞의 두 유형 중 하나를 가리키는 더 작은 참조입니다.

64바이트 이하의 바이너리는 힙 바이너리로서 프로세스 힙에 직접 저장될 수 있습니다. 이보다 큰 바이너리는 참조 카운트되며 페이로드는 프로세스 힙 바깥에 저장되고, 페이로드에 대한 참조는 ProcBin이라는 객체에 담겨 프로세스 힙에 저장됩니다.

헤더 다음에는 다음 내용이 옵니다:

서브 바이너리(서브태그 1010)는 기존 바이너리를 가리키는 뷰입니다. 서브 바이너리는 길이 필드와 오프셋 필드를 담은 헤더 워드 하나와 그 뒤에 오는 머신 워드 두 개를 저장합니다. 덕분에 바이너리의 일부를 잘라 내거나 매칭할 때 페이로드 데이터를 복사할 필요가 없습니다.

매치 컨텍스트(서브태그 0001, BINARY_AGGREGATE)는 바이너리 패턴 매칭 엔진에서 사용됩니다. 매치 컨텍스트는 새 페이로드 공간을 할당하지 않고, 자신을 감싸는 하나 이상의 바이너리에서 세그먼트를 참조합니다:

이를 통해 데이터를 평탄화하거나 복사하지 않고도 효율적으로 순회할 수 있습니다.

바이너리에 대해서는 Chapter 11에서 더 자세히 다루겠습니다.

작은 즉시값(워드 크기에서 태그 비트 4개를 뺀 크기)에 담을 수 없을 만큼 큰 정수는 bignum으로 표현됩니다. bignum은 박스형 텀이며, 그 헤더 워드에는 부호와 뒤따르는 “림(limb)” 워드의 개수가 함께 인코딩됩니다. 헤더의 기본 태그(00)는 이것이 힙에 할당된 헤더임을 나타내고, 4비트 서브태그(001)는 이것이 bignum임을 식별하며, 그 서브태그의 최상위 비트는 부호(0 = 양수, 1 = 음수)를 담습니다. 뒤따르는 각 림은 정수의 일부를 2^D_EXP 진법(일반적으로 32비트 빌드에서는 28비트, 64비트 빌드에서는 60비트)으로 담는 완전한 머신 워드이며, 리틀 엔디언 순서(최하위 림이 먼저)로 배치됩니다.

다중 정밀도 산술 연산은 이 림 배열을 직접 다룹니다. 덧셈과 뺄셈은 올림(carry)이나 빌림(borrow)을 전파하면서 림을 워드 단위로 훑는 방식으로 구현되며(I_add/I_sub), 그 결과로 림 배열을 내놓습니다. 마지막에 올림이 남으면 이 배열의 길이가 하나 늘어날 수 있습니다. 곱셈은 림 수가 적을 때는 이차 시간이 드는 교과서식 알고리즘(I_mul)을, 피연산자 길이가 임곗값을 넘을 때는 카라추바(Karatsuba) 분할 정복 방식(I_mul_karatsuba)을 사용하며, 중간 단계의 배정밀도 곱은 상위 절반과 하위 절반으로 나눕니다. 나눗셈과 나머지 연산은 커누스(Knuth)의 알고리즘 D(I_div/I_rem)를 사용하여 몫과 나머지 림 배열을 계산하며, 결과의 부호는 피연산자의 부호에 따라 조정합니다.

내부적으로 각 림(limb)은 ErtsDigit 타입이며, bignum의 림 배열에는 BIG_V(xp) 매크로로 접근합니다. 이 매크로는 최하위 워드를 가리키는 ErtsDigit* 포인터를 반환합니다. 개별 림은 BIG_DIGIT(xp, i)(0부터 시작하는 인덱스, 리틀 엔디언)로 읽거나 씁니다. big.c 파일의 모든 핵심 루틴(예: I_add, I_sub, I_mul, I_mul_karatsuba, I_div, I_rem)은 이러한 ErtsDigit* 배열을 직접 다루며, 올림/빌림, 다중 정밀도 곱셈, 긴 나눗셈 단계를 처리합니다. 결과 자릿수가 계산되면 big_norm이 박스형 헤더(태그, 애리티, 부호)를 다시 계산하며, 결과가 태그 비트 안에 들어갈 수 있으면 결과를 작은 즉시값(small immediate)으로 되돌리기도 합니다.

레퍼런스는 “unique” 텀으로, 기본적으로 프로세스 메일박스 위에 채널을 구현하기 위해 메시지에 태그를 붙이는 데 자주 사용됩니다. 레퍼런스는 82비트 카운터로 구현됩니다. make_ref/0을 9671406556917033397649407번 호출하고 나면 카운터가 한 바퀴 돌아 다시 ref 0부터 시작합니다. 평생 make_ref를 그만큼 많이 호출하려면 정말 빠른 머신이 필요합니다. 다만 노드를 재시작하면 이야기가 다릅니다. 이 경우에도 카운터는 다시 0부터 시작하지만, 그때는 이전의 로컬 ref가 모두 사라진 상태입니다. ref를 다른 노드로 보내면 그 ref는 외부 ref가 됩니다. 아래를 참조하십시오.

32비트 시스템에서 로컬 ref는 힙에서 32비트 워드 네 개를 차지합니다. 64비트 시스템에서 ref는 힙에서 64비트 워드 세 개를 차지합니다.

참조 번호는 (Data2 bsl 50) + (Data1 bsl 18) + Data0입니다.

Erlang 부동소수점 수는 FLONUM 서브태그가 붙은 박스형 힙 텀입니다. 각 부동소수점 수는 머신 워드 두 개를 차지합니다. 하나는 헤더 워드(기본 태그 00, 서브태그 0110)이고, 다른 하나는 64비트 IEEE 754 페이로드 워드입니다. 에뮬레이터는 가비지 컬렉션과 비교에서 부동소수점 수를 불투명한 “박스형” 값으로 취급합니다. 산술 연산에는 가능하면 네이티브 CPU 명령어를 사용하고, 그렇지 않으면 소프트웨어 루틴으로 대체합니다.

레코드는 튜플을 기반으로 한 컴파일 타임 편의 기능입니다. 애리티가 N인 레코드는 N개의 요소로 이루어진 튜플일 뿐이며, 첫 번째 요소는 레코드의 이름을 나타내는 아톰입니다. 접근 매크로와 갱신 매크로는 고정 인덱스 튜플 조회나 setelement/3 호출로 변환됩니다. 튜플 헤더(기본 태그 00, 서브태그 0000)가 arity를 인코딩하므로, 레코드 크기와 필드 오프셋은 추가 메타데이터 없이도 런타임에 알 수 있습니다.

어쨌든 BEAM은 스택 머신이 아닙니다. BEAM은 레지스터 머신입니다. 레지스터 머신에서는 명령어 피연산자가 스택이 아닌 레지스터에 저장되며, 연산 결과는 대개 특정 레지스터에 담깁니다. BEAM에서 레지스터는 X 레지스터(X0, X1, …​)라고 부르는 워드 크기의 메모리 위치이며, 실행 중인 프로세스 전용입니다.

대부분의 레지스터 머신에는 여전히 함수에 인자를 전달하고 반환 주소를 저장하는 데 쓰이는 스택이 있습니다. 스택에서 특정 함수 호출에 관한 정보를 담는 구역을 스택 프레임이라고 하며, 여기에는 반환 주소, 레지스터에 들어가지 않는 입력 인자와 지역 변수, 그리고 서브루틴을 호출하는 동안 임시로 저장해 두는 값이 담깁니다. ^[3]

BEAM에는 스택이 있으며, 스택 프레임의 모든 항목은 X 레지스터와 마찬가지로 균일하게 워드 크기입니다. 따라서 이 항목들은 간단히 Y 레지스터(Y0, Y1, …​)라고 부릅니다 — 이는 WAM [Warren]에서 빌려 온 용어입니다. 다시 말해, BEAM 명령어가 Y0을 참조한다면 이는 현재 호출의 스택 프레임에 있는 슬롯 0을 의미하며,

X 레지스터는 범용 레지스터이지만 호출되는 함수에 인자를 전달하는 데에도 사용되며, 레지스터 X0(때로는 R0이라고도 부릅니다)은 반환값을 담는 데 사용됩니다. 이 레지스터들은 하드웨어 레지스터가 아니라 단순한 메모리 위치이므로, 실제 CPU에서만큼 한정된 자원이 아닙니다(실제 CPU에서는 레지스터가 32개만 있어도 많은 편으로 여겨집니다). BEAM에서는 1024개의 X 레지스터를 사용할 수 있으므로 함수 인자를 스택으로 전달할 필요가 전혀 없습니다. (다만 함수 호출 전후로 값을 유지하려면 “caller saves” 규약에 따라, 살아 있는 다른 X 레지스터의 현재 내용을 스택의 Y 레지스터에 저장해 두어야 합니다.)

X 레지스터는 BEAM 에뮬레이터 안의 C 배열에 저장되며(스케줄러마다 따로 존재합니다), 모든 함수에서 전역적으로 접근할 수 있습니다. X0 레지스터는 지역 변수에 캐시되며, 이 지역 변수는 대부분의 아키텍처에서 물리적인 머신 레지스터에 유지됩니다. X0은 매우 빈번하게 사용되므로 이는 중요한 최적화입니다.

Y 레지스터는 현재 스택 프레임에 저장되며, 현재 실행 중인 함수만 접근할 수 있습니다. 함수 호출 뒤에도 값을 유지하기 위해 BEAM은 스택 프레임에 그 값을 담을 공간을 할당한 다음, 값을 해당 Y 레지스터로 옮깁니다. 공간이 예약되지 않은 Y 레지스터에 값을 쓰는 것은 허용되지 않습니다. 그렇게 하면 힙을 덮어쓸 수 있기 때문입니다.

BEAM에는 X 레지스터와 Y 레지스터 외에도 여러 특수 목적 레지스터가 있습니다.

Htop이나 E 같은 레지스터는 PCB의 해당 필드 값을 캐시해 둔 것입니다. 프로세스가 타임 슬라이스를 모두 소진하면 이 값들이 PCB에 다시 기록되고 다른 프로세스가 실행됩니다. BEAM이 한 프로세스를 다른 프로세스로 교체하는 시점을 결정하는 방식(일종의 협력형 멀티태스킹이라고 볼 수 있는 방식을 사용합니다)([Process Switching] 참조) 때문에, 이러한 교체가 일어날 때 모든 X 레지스터를 저장하고 복원할 필요가 없습니다 — 저장해야 하는 모든 것은 그 시점에 Y 레지스터에 들어 있기 때문입니다.

프레임 포인터(FP)가 반드시 “real” BEAM 레지스터일 필요는 없습니다 — 현재 스택 프레임의 크기를 알고 있다면 스택 최상단으로부터 계산할 수 있기 때문입니다. 그러나 이를 별도로 추적하면 구현의 다른 부분이 더 쉬워질 수 있으며, 설명도 간단해지므로 여기서는 FP가 존재하는 것처럼 다루겠습니다.

BEAM이 호출 명령어를 실행하면 연속 포인터(Continuation Pointer, CP)가 반환 주소로 설정됩니다. 반환 주소를 스택에 직접 푸시하지 않고 CP에 보관하므로, 반환 명령어는 I의 새 값을 CP와 같게 설정하고 실행을 계속하기만 하면 됩니다. 이는 평균적으로 전체 호출(꼬리 호출 제외)의 절반이 리프 함수, 즉 다른 함수를 더 이상 호출하지 않는 함수에 대한 호출이라는 사실에 기반한 최적화입니다. 리프 함수를 호출할 때는 반환 주소를 스택에 저장할 필요가 없습니다. 대신 리프가 아닌 함수만 CP를 스택에 저장했다가 반환하기 전에 복원하면 됩니다.

Figure 23는 Y 레지스터 두 개를 사용하고 CP를 스택에 저장한 함수를 예로 들어, BEAM에서 레지스터와 스택 프레임이 어떻게 배치되는지 보여 줍니다. X 레지스터와 Y 레지스터에는 즉시값이나 힙을 가리키는 태그된 포인터(Chapter 4 참조)가 들어갈 수 있지만, 스택 슬롯을 가리키는 일은 결코 없습니다. 예를 들어 스택 프레임 안에 저장되는 튜플은 없습니다.

다음 프로그램을 'S' 플래그로 컴파일해 봅시다:

그러면 add/2 함수에 대해 다음과 같은 코드를 얻게 됩니다:

관례에 따라 함수에 진입할 때 첫 번째 인자 A는 X0으로, 두 번째 인자 B는 X1로 전달됩니다. 코드(레이블 2부터 시작)가 먼저 스택 슬롯 하나만큼의 공간을 할당하는 것을 볼 수 있습니다.^[4] 이렇게 하면 함수 호출 id(A) 동안 Y0을 사용해 X1의 값을 보존할 수 있으며, 이 작업은 {move,{x,1},{y,0}} 명령어가 수행합니다(“move X1 to Y0”로 읽거나, 명령형 스타일로는 y0 := x1로 씁니다).

인자 A는 이미 X0(첫 번째 인자 레지스터)에 있으므로, 레이블 {f,4}에 있는 id/1 함수(여기서는 보이지 않음)를 {call,1,{f,4}}로 직접 호출할 수 있습니다. (피연산자 "1"이 무엇을 뜻하는지는 나중에 다시 다루겠습니다.) 그런 다음 호출 결과(X0으로 반환됨)를 스택에 저장해야 하지만, Y0 슬롯은 이미 인자 B가 차지하고 있습니다. 다행히 이런 경우를 처리하는 swap 명령어가 있으므로, 먼저 Y0를 X1로, 다음으로 X0를 Y0로, 마지막으로 X1을 X0로 옮기는 세 개의 명령어를 사용하지 않아도 됩니다.

이제 X0에 두 번째 인자 B가 들어 있으므로, {call,1,{f,4}}로 id/1 함수를 다시 호출할 수 있습니다. 이 호출 뒤에는 X0에 id(B)가, Y0에 id(A)가 들어 있습니다. 내장 함수 +/2를 {gc_bif,'+',{f,0},1,[{y,0},{x,0}],{x,0}}로 호출하여 덧셈을 수행할 수 있습니다. (BIF 호출과 GC에 대해서는 뒤에서 자세히 다루겠습니다.) 결과는 다시 X0에 들어가며, 이곳은 add/2에서 반환하기 위해 결과가 있어야 하는 바로 그 위치입니다. 반환하기 전에는 deallocate 명령어로 스택 포인터를 다시 되돌리기만 하면 되며, 그러면 함수가 끝납니다.

산술 식을 위한 단순한 스택 머신을 살펴보면, 실행할 명령어를 선택하기 위해 Erlang 아톰과 패턴 매칭을 사용한다는 것을 알 수 있습니다. 이는 기계 명령어를 디코딩하는 일만 하기에는 매우 무거운 장치입니다. 실제 머신 구현에서는 각 명령어를 "머신 워드" 정수나 심지어 단일 바이트로 코딩할 것입니다.

우리의 스택 머신을 C로 구현한 바이트코드 머신으로 다시 작성할 수 있습니다. 먼저 간단한 컴파일러가 바이트코드를 생성하도록 다시 작성합니다. 이 작업은 간단합니다. 아톰으로 인코딩된 각 명령어를 해당 명령어를 나타내는 바이트로 바꾸기만 하면 됩니다(아래 참조). 255보다 큰 정수를 처리할 수 있도록, 크기 바이트 뒤에 바이트 단위로 인코딩된 정수가 오는 형식으로 정수를 인코딩합니다.

이제 C로 간단한 가상 머신과 바이트코드 인터프리터를 작성해 봅시다. (전체 코드는 온라인 부록에서 확인할 수 있습니다.)

보시다시피 C로 작성된 가상 머신은 그리 복잡할 필요가 없습니다. 이 머신은 단지 하나의 루프로, 각 명령어마다 명령어 포인터(ip)가 가리키는 값을 확인하여 바이트코드를 검사합니다.

각 바이트코드 명령어마다 명령어 바이트코드에 따라 분기하여 해당 명령어를 실행하는 case로 점프합니다. 이를 위해서는 명령어를 디코딩한 다음 올바른 코드로 점프해야 합니다. vsm.c의 어셈블리(gcc -S vsm.c)를 살펴보면 디코더의 내부 루프를 확인할 수 있습니다:

바이트코드를 각 명령어 코드와 비교한 다음 조건부 점프를 수행해야 합니다. 명령어가 많은 실제 머신에서는 이 작업의 비용이 상당히 커질 수 있습니다.

더 나은 해결책은 코드의 주소를 담은 테이블을 두는 것입니다. 그러면 테이블의 인덱스로 주소를 불러와 아무런 비교 없이 바로 점프할 수 있습니다. 이 기법은 때때로 토큰 스레드 코드라고 불립니다. 여기서 한 걸음 더 나아가, 명령어를 구현하는 코드 조각의 주소를 코드 메모리에 “instruction” 그 자체로 저장할 수도 있습니다. 그러면 인터프리터 루프가 단일 바이트 대신 다음 주소를 읽고, 그 주소에 있는 루틴을 호출한 뒤, 루틴이 반환되면 그저 다음 주소로 넘어가도록 할 수 있습니다. 이를 subroutine threaded code 방식이라고 부릅니다. 다만 이 방식에서는 코드가 훨씬 더 많은 공간을 차지한다는 점에 유의하십시오. 명령어마다 단일 바이트 대신 워드 하나 전체를 사용하기 때문입니다. 그러나 메모리가 넉넉한 하드웨어에서는 대개 속도상의 이점 덕분에 그만한 가치가 있습니다. (토큰 스레드 코드(token threaded code)는 메모리가 부족하고 속도가 상대적으로 덜 중요할 수 있는 환경에서 자주 사용됩니다.)

이 방식은 런타임의 실행을 더 단순하게 만들지만, 로더가 필요하므로 VM을 더 복잡하게 만듭니다. 로더는 바이트코드 명령어를 그 명령어를 구현하는 함수의 주소로 치환합니다.

로더는 다음과 같은 형태일 수 있습니다:

보시다시피 여기서는 255보다 큰 정수의 디코딩을 포함하여 로드 시점에 더 많은 작업을 수행합니다. (네, 알고 있습니다. 이 코드는 매우 큰 정수에 대해서는 안전하지 않습니다.)

하지만 VM의 디코드 및 디스패치 루프는 상당히 단순해집니다:

마지막으로, 각 명령어 조각을 반환하는 함수로 만드는 대신, 메인 루프가 다음 명령어를 읽고 그곳으로 점프할 때 사용하는 것과 동일한 작은 코드 조각으로 각 조각이 끝나도록 코드를 작성할 수 있습니다. 이렇게 하면 메인 루프와 조각 사이를 오가는 일이 없어집니다 — 실제로 메인 루프 자체가 사라지고, 각 명령어 조각이 다음 명령어로 이어지도록 보장할 책임을 개별적으로 지게 됩니다. 이 기법을 직접 스레드 코드라고 부릅니다. 이를 C로 구현하기 위해 BEAM은 GCC의 “labels as values” 확장 기능을 사용합니다.

BEAM 에뮬레이터는 나중에 더 자세히 살펴보겠지만, 지금은 실제 BEAM add 명령어가 어떻게 구현되어 있는지 간단히 살펴보겠습니다. 이 코드는 매크로를 많이 사용하기 때문에 따라가기가 다소 어렵습니다. STORE_ARITH_RESULT 매크로는 사실 디스패치 함수를 감추고 있으며, 이 함수는 대략 I += 4; Goto(*I);와 같은 형태입니다.

BEAM 디스패처가 어떻게 구현되어 있는지 조금 더 쉽게 이해할 수 있도록, 다소 가상적인 예제를 하나 들어 봅시다. 실제 외부 BEAM 코드로 시작하겠지만, 그다음에는 내부 BEAM 명령어 몇 가지를 제가 새로 만들어 C로 구현해 보겠습니다.

Erlang으로 작성한 간단한 add 함수부터 살펴봅시다.

BEAM 코드로 컴파일하면 다음과 같습니다(정확히는 swap 명령어가 추가되기 전에는 이와 같았습니다 — Section 5.1.2 참조):

(전체 코드는 온라인 부록의 add.erl과 add.S를 참고하십시오.)

이제 이 코드에서 함수 호출 사이에 있는 세 개의 명령어를 자세히 살펴보면 다음과 같습니다:

이 코드는 먼저 함수 호출의 반환값(x0)을 레지스터 x1로 옮깁니다. 그다음 이전에 저장해 둔 B를 스택 슬롯 y0에서 첫 번째 인자 레지스터(x0)로 옮깁니다. 마지막으로 x1의 값을 스택 슬롯(y0)으로 옮겨 다음 함수 호출 이후에도 그 값이 유지되도록 합니다.

BEAM에 move_xx, move_yx, move_xy라는 세 가지 명령어를 구현한다고 가정해 봅시다(이 글을 쓰는 시점에 실제 BEAM에는 이러한 명령어가 존재하지 않으며, 이 예시를 설명하기 위해 사용할 뿐입니다):

goto *의 별표는 역참조를 뜻하지 않는다는 점에 유의하십시오. 이 표현식은 주소 포인터로 점프한다는 의미이므로, 사실은 goto*로 쓰는 것이 맞습니다.

이제 이 명령어들에 대해 컴파일된 C 코드가 메모리 주소 0x3000, 0x3100, 0x3200에 위치하게 된다고 가정해 봅시다. BEAM 코드가 로드되면 코드 안에 있는 세 개의 move 명령어는 각 명령어 구현부의 메모리 주소로 대체됩니다. 코드({move,{x,0},{x,1}}, {move,{y,0},{x,0}}, {move,{x,1},{y,0}})가 주소 0x1000에 로드된다고 가정해 봅시다:

주소 0x1000에 있는 워드는 move_xx 명령어의 구현을 가리킵니다. I 레지스터가 0x1000을 가리키는 명령어 포인터를 담고 있다면, 디스패치는 *I(즉, 0x3000)를 가져와 그 주소로 점프하는 동작(goto* *I)이 됩니다.

Chapter 7에서는 실제 BEAM 명령어 몇 가지와 그 구현 방식을 더 자세히 살펴보겠습니다.