>`のようにバイナリをマッチさせると、小さいほうのバイナリ（`Rest`）は元の大きなバイナリを参照し続けます。コピーを避けられるのは利点ですが、ほんの一部を参照するために巨大なバイナリを生かしたままにしてしまっていた、と気づくこともあります。そのような場合は`binary:copy/1`を呼ぶとよいでしょう。
メモリが原因不明に増え続ける場合は、プロセスに残ったままの参照によって大きなバイナリが居座っていないか確認してください。
ときには、`erlang:garbage_collect/1`でガベージコレクタにそっと働きかけたり、プロセスをハイバネートさせたりして、メモリの回収を早める必要があるかもしれません。
### ETSアロケータ: ets_alloc
`ets_alloc`アロケータは、おなじみのETS（Erlang Term Storage）テーブル用のメモリを管理します。
デフォルトでは、ETSテーブルは個々のプロセスに結び付けられていないため、プロセスが自分のガベージを片付けても、ETSテーブルはそのまま残ります。
いくつか重要な点を押さえておいてください。
- **長命なデータ**：ETSテーブルにデータを置くと、そのデータはプロセスヒープを離れ、専用のアロケータに落ち着きます。通常のプロセスのガベージコレクションでは、この領域は片付けられません。メモリを取り戻したいなら、明示的にデータを削除するかテーブルを削除する必要があります。
- **多様な用途**：このアロケータは、古典的なハッシュテーブルから凝った`ordered_set`構造、内部のメタデータまで、ETSに関するあらゆるものを扱います。人気のあるテーブルや大きなテーブルは、あっという間にメモリを大量消費する存在になりかねないので注意してください。
- **短命なETSデータ**：ETSは、マッチングや中間結果のような手早い作業のために、他のアロケータを一時的に借りることがあります。しかし主なデータは`ets_alloc`に置かれます。
ETSテーブルは驚くほど大きくなることがあるので、ときどき`ets:info(Tab, memory)`のような関数でサイズを確認するか、システムメトリクスを通じて`ets_alloc`全体の使用量に目を配ってください。
### ドライバアロケータ: driver_alloc
ドライバアロケータは、ポートやリンクインドライバ、NIFリソース用のメモリを扱います。
平たく言えば、I/Oドライバや外部ライブラリ、ファイルディスクリプタとやり取りするなど、Erlangの安全網の外側に手を伸ばすときには、ここに行き着きます。
押さえておきたい点は次のとおりです。
- **ポートとドライバのデータ**：ここでの確保には、ネットワークソケットや開いたファイルディスクリプタの構造体、リンクインドライバ固有のバッファが含まれます。
- **NIFが確保するデータ**：NIFが`enif_alloc`で手を伸ばすと、そのメモリは最終的にこのアロケータから来ます。VMは、`enif_free`が呼ばれるか、NIFオブジェクトがステージから退場するまで、律儀に待ってからこの領域を回収します。
- **外部起因のリークの可能性**：NIFやドライバはErlangの通常のメモリ安全ルールを迂回するため、行儀の悪いドライバが意図せずメモリを握ったままになり、デジタル版の水漏れ蛇口のような状態を生むことがあります。`driver_alloc`の使用量に目を配っておくと、こうした漏れに気づきやすくなります。
開発者が`driver_alloc`を直接操作することはめったにありませんが、とくにNIFを使っている場合は、本番環境でこのアロケータを監視しておくのが賢明です。
### 短命アロケータ: sl_alloc
短命アロケータ（`sl_alloc`）は、一時的な確保のような瞬き一つで見逃すほどの寿命よりは長いものの、それほど長くはないデータ構造のためのメモリを扱います。
挨拶を交わしてさっとコーヒーを飲んだら立ち去る程度に居座るメモリ、といったイメージです。典型的な例には次のものがあります。
- **中間バッファ**：短い処理のために必要な小さなバッファで、スケジューリングポイントをいくつかまたいで短く居座りますが、一晩泊まっていくつもりは決してありません。
- **一時的なリスト**：短命なシステムメッセージバッファや短命なスケジューリングメタデータのような、一時的なランタイム構造です。気づいたときにはもう消えています。
Erlang/OTPは、マッチ状態オブジェクトや一時的なI/Oバッファなど、つかの間の処理に`sl_alloc`を活用しています。
これらの確保は本当に一時的なメモリよりは長生きしますが、それでも速やかに立ち去り、痕跡をほとんど残さないことが期待されています。
アプリケーションがとりわけおしゃべりで（頻繁な小さいドライバ呼び出しや短い計算など、短命な確保を大量に生成する場合）、`sl_alloc`がかなり熱くなることがあります。
`recon_alloc:usage()`のようなツールで使用状況を確認すれば、`sl_alloc`が使われすぎていないかわかります。
### 長命アロケータ: ll_alloc
長命アロケータは、Erlangノード自体と同じくらい長く、長期間生き続けることを意図したデータを扱います。典型的な例には次のものがあります。
- **アトム**：アトムは一度作られると無期限に残り続け、`ll_alloc`の永続的な住人になります。
- **ロード済みモジュールとコード**：コンパイル済みモジュールやエクスポートされた関数、無名関数（`fun`）に関するメタデータもここに格納されます。例えば`code:load_file(my_module)`でモジュールをロードすると、そのメタデータは`ll_alloc`に置かれます。
- **スケジューラとシステムの構造体**：スケジューラの実行キュー（`run_queue`）やpollset情報（`pollset`）、プロセスレジストリ（`proc_tab`）といった内部ランタイム構造は、VMの動作に不可欠なのでここに置かれます。
`ll_alloc`にあるオブジェクトは居座りがちなので、このアロケータは通常、ノードの生存期間を通じてゆっくりとですが継続的に増えていきます。
システムが頻繁にモジュールをロード・アンロードしていると、変動が見られることがあります。例えば、古いバージョンを適切にアンロードしないままホットコードロードを繰り返すと、`ll_alloc`のメモリ使用量が徐々に膨らんでいくことがあります。
実際には、明示的にモジュールをアンロードするかノードを再起動しない限り、ほとんどのシステムはここからあまりメモリを取り戻せません。
そのため、とくにアプリケーションが動的にモジュールや大量の長期データを管理している場合は、`recon_alloc:usage(ll_alloc)`をときどき確認して、予想外のスパイクやフラグメンテーションがないか見ておくのが賢明です。
### 固定サイズアロケータ: fix_alloc
固定アロケータ`fix_alloc`は、固定サイズのオブジェクト、つまり典型的にはサイズが変わらない小さなC構造体（メッセージ参照、ドライバイベントデータ、モニタなど）の確保に特化しています。
これらのオブジェクトは一様なサイズなので、アロケータは効率よく扱えます。
デフォルトで`fix_alloc`は"Address Order Best Fit"を使い、解放されたオブジェクトを同じサイズのブロックのリストへきちんと戻すことで、フラグメンテーションを効果的に抑えます。
違うサイズのピースを箱に無造作に放り込むのではなく、同じ形のレゴブロックをきれいに積み重ねるようなものです。
例としては、`ErlMessage`のような内部VM構造体、モニタの参照、スケジューラの管理用データなどがあります。
開発者が`fix_alloc`と直接やり取りすることは通常ありませんが、システムレベルでは欠かせない存在です。
ここでの効率的な確保のおかげで、ランタイムは細かく断片化した確保の管理に足を取られずに済み、Erlangが並行処理を優雅にこなすという評判を保つ助けになっています。
### 標準アロケータ: std_alloc
メモリがErlangの特化アロケータのどれにもきれいに当てはまらない場合、`std_alloc`に居場所を見つけます。ランタイムの何でも屋的な受け皿アロケータです。
Erlangにおけるメモリの「雑多引き出し」だと考えてください。
このアロケータは、雑多な種類の確保を扱います。短命か長命か曖昧な一時データへの参照、動的にサイズが決まる構造体、明確に分類できないVMサブシステムのデータ、あるいは単に他のどこにもきれいに分類できないほど独特なメモリ確保などが含まれます。
他のアロケータと同様、`+Ms`や`+Msbct`のような起動時フラグで`std_alloc`の挙動を調整できます。
普段は放っておいて構いませんが、必要なときには調整できることを知っておくとよいでしょう。
トラブルシューティングでは、`std_alloc`が原因不明のメモリスパイクの第一容疑者になることがあります。
`erlang:system_info({allocator, std_alloc})`や`recon_alloc`のようなツールを使えば、想定より多くのメモリを抱え込んでいないかすぐにわかります。
`std_alloc`はきれいに分類できないメモリ要求を集めるため、忙しいノードではかなりの使用量を蓄積するのが普通です。
このアロケータが一貫して増え続けているのを見たら、通常はアプリケーションの挙動を再確認するか、何が「普通」かという前提を見直すべきサインです。
### リテラルアロケータ: literal_alloc
`literal_alloc`は、しばしば**リテラルプール**と呼ばれる、ロード済みErlangモジュール内のコンパイル時定数を格納します。
コンパイル時に定義された大きな静的バイナリやタプル、リストのような定数を、Erlangが安全に保管しておくVMの「読み取り専用メモリ棚」だと考えてください。
典型的なアロケータと違い、`literal_alloc`はスケジューラごとではなくグローバルに管理されます。リテラルは実行中に頻繁に変更されたり回収されたりしないためです。
一度ロードされたリテラルは、対応するモジュールが明示的にパージまたはリロードされるまで残り続けます。
`literal_alloc`の監視は普段は特に何も起きませんが、モジュールの動的な更新が頻繁だったり、リテラルの多い大きなモジュールを繰り返しロードしたりする場合は、様子を見ておく価値があります。
## スケジューラごとのアロケータインスタンス
現代のOTP（R13B以降）では、ここまで説明してきたメモリアロケータの大半（`eheap_alloc`、`binary_alloc`、`ets_alloc`など）が複数のインスタンスを持ち、SMP（対称型マルチプロセッシング）環境での競合を最小限に抑えます。
デフォルトでは、各スケジューラスレッドがこれらのアロケータの自分専用のインスタンスを1つ持ち、さらにドライバの非同期スレッドが共有する追加のインスタンスが1つあります。
このスケジューラごとの確保方式によってメモリ管理が分割され、ロックの競合が大幅に減り、マルチコアシステムでのスケーラビリティが向上します。
これはまた、メモリ使用量とフラグメンテーションがスケジューラごとに別々に扱われることも意味しており、メモリ統計をどう解釈するか、メモリ関連の問題をどうトラブルシューティングするかに影響することがあります。
アロケータのメトリクスを調べるとき（`recon_alloc`や`erlang:system_info`を通じてなど）、複数のアロケータインスタンスにまたがって集計された統計を目にします。
メモリパターンを分析する際は、この点に注意してください。
## メモリ用のシステムフラグ
メモリアロケータのシステムフラグは、次のような構文に従います。
```
+M
```
- ``はアロケータを識別する大文字1文字です。
- ``はパラメータを指定します。
- ``は使用する値を指定します。
**アロケータの識別子（``）：**
- `B`：binary_alloc
- `D`：std_alloc
- `E`：ets_alloc
- `F`：fix_alloc
- `H`：eheap_alloc
- `I`：literal_alloc
- `L`：ll_alloc
- `M`：mseg_alloc
- `R`：driver_alloc
- `S`：sl_alloc
- `T`：temp_alloc
- `Y`：sys_alloc
- `u`：alloc_util（alloc_utilベースのすべてのアロケータに影響）
## よく使われるフラグ
**確保戦略（`as`）：**
キャリア内でどうメモリブロックを選ぶかを決めます。
- `bf`：Best fit
- `aobf`：Address order best fit
- `aoff`：Address order first fit
- `aoffcbf`：Address order first fit carrier best fit
- `ageffcbf`：Age order first fit carrier best fit
- `gf`：Good fit
- `af`：A fit
例。
```
+MBas bf
```
（バイナリアロケータがbest-fit戦略を使います。）
**Singleblock Carrier Threshold（`sbct`）：** 確保がシングルブロックキャリアを使うようになる、KB単位の閾値を定めます。
例。
```
+MBsbct 1024
```
（1024KBを超えるバイナリの確保がシングルブロックキャリアを使います。）
**マルチブロックキャリアの設定：**
- **最小（`smbcs`）・最大（`lmbcs`）マルチブロックキャリアサイズ**：マルチブロックキャリアの最小・最大サイズ（KB）を制御します。
- **キャリア成長段階（`mbcgs`）**：最小値と最大値の間でのキャリアサイズの成長を定めます。
例。
```
+MBsmbcs 512 +MBlmbcs 8192
```
（バイナリアロケータのマルチブロックキャリアは512KBから8MBの範囲になります。）
**Abandon Carrier Utilization Limit（`acul`）：** これを下回る使用率のキャリアが放棄され、再利用されるパーセンテージの閾値です。
例。
```
+MBacul 50
```
（使用率が50%未満のバイナリキャリアは放棄済みとしてマークされます。）
**Abandon Carrier Free Utilization Limit（`acful`）：** この使用率を下回ると、VMは未使用メモリを回収してよいとOSに伝えます。
例。
```
+MDacful 10
```
（`std_alloc`は、使用率が10%未満ならメモリをOSが回収可能だとマークします。）
**Multiple Thread-specific Instances（`t`）：** アロケータが（スケジューラごとに1つの）複数インスタンスを使うかどうかを制御します。
例。
```
+MHt true
```
（`eheap_alloc`がスケジューラスレッドごとに別々のアロケータインスタンスを使います。）
**Allocation Tagging（`atags`）：** 確保にタグを付け、計装を使ったデバッグに役立ちます。
例。
```
+MRatags true
```
（`driver_alloc`のタグ付けを有効にします。）
## mseg_alloc向けの特殊フラグ
`mseg_alloc`（メモリセグメントアロケータ）には、専用の設定があります。
- **Super Carrier Size（`scs`）：** `+MMscs 1024`（1GBのスーパーキャリアを作ります。）
- **Use Large Pages（`lp`）：** `+MMlp on`（ラージ／ヒュージページのサポートを有効にします。）
- **Super Carrier Only（`sco`）：** `+MMsco true`（確保はスーパーキャリア内でのみ行われます。）
- **Maximum Cached Segments（`mcs`）：** `+MMmcs 20`（キャッシュ済みセグメントを最大20個まで保持します。）
## sys_alloc向けの特殊フラグ
`sys_alloc`は、システムのmallocとやり取りします。
- **Trim Threshold（`tt`）：** 空きヒープが閾値を超えたときにメモリをOSへ返却します。`+MYtt 256`（トリム閾値を256KBに設定します。）
- **Top Pad（`tp`）：** その後の呼び出しを減らすため、mallocがOSに追加で要求する余剰メモリです。`+MYtp 512`（mallocが512KBのパディングを要求します。）
## リテラルアロケータ（literal_alloc）
リテラル（コンパイル時定数）を格納します。
- **Literal Super Carrier Size（`scs`）：** `+MIscs 2048`（リテラルアロケータのスーパーキャリアを2GBに設定します。）
## グローバルフラグと便利フラグ
- **Minimal/Maximal Allocation Setup（`ea`）：** `+Mea min|max|config`（全アロケータ向けの設定プリセットです。）
- **Lock Physical Memory（`lpm`）：** `+Mlpm all|no`（VMのメモリを物理RAMにロックします。）
- **Dirty Allocator Instances（`dai`）：** `+Mdai max|`（ダーティスケジューラ専用のアロケータインスタンスです。）
## 実践的な例
全アロケータでaddress-order best fitを使い、フラグメンテーションを減らします。
```
+Muas aobf
```
ETSアロケータの最大メモリを制限します（例えば2GB）。
```
+MEamax 2097152
```
全アロケータでデバッグ用の確保タグ付けを有効にします。
```
+Muatags true
```
## 推奨事項
- 問題が起きない限り、デフォルト設定から始めましょう。
- チューニングの前に、`erlang:system_info/1`や`recon_alloc`でアロケータの使用状況を監視しましょう。
- 変更は、制御された環境で少しずつ試しましょう。
- ベンチマークとプロファイリングなしに、積極的なチューニングをしないようにしましょう。
{{< message >}}
ここまで説明してきたメモリアロケータのフラグの大半は、実装に強く依存しています。
その挙動や利用可否、デフォルト値は、事前の告知なしに変更されたり、完全に削除されたりすることがあります。
さらに、ランタイム（`erts_alloc`）は、内部のヒューリスティックやシステムの制約に基づいて、指定された設定を無視したり調整したりすることがあります。
設定は必ず、実際のシステムメトリクスとテストで検証してください。
{{< /message >}}
## プロセスメモリ
[プロセスの章](../processes/#CH-Processes)で見たように、プロセスとは実質的にいくつかのメモリ領域の集まりにすぎません。本章では、スタックとヒープ、そしてメールボックスがどのように管理されているかを、もう少し詳しく見ていきます。
スタックとヒープのデフォルトサイズは233ワードです。
このデフォルトサイズは、Erlangの起動時に`+h`フラグでグローバルに変更できます。
`spawn_opt`でプロセスを起動する際に`min_heap_size`を設定すれば、最小ヒープサイズを個別に指定することもできます。
[型システムの章](../type_system/#CH-TypeSystem)で見たように、Erlangのタームはタグ付けされており、ヒープに格納されるときはコンス（cons）セルかboxedオブジェクトのどちらかになります。
### タームの共有
ヒープ上のオブジェクトは、1つのプロセスの中では参照によって受け渡されます。
タプルを引数にして関数を呼び出すと、そのタプルへのタグ付き参照だけが呼び出し先の関数に渡されます。
新しいタームを組み立てるときも、サブタームへの参照だけを使います。
例えば文字列`"hello"`（整数のリスト`[104,101,108,108,111]`と同じです）があるとき、メモリレイアウトはおおよそ次のようになります。
*図: 変数Lに束縛されたリスト"hello"のメモリレイアウト*
このリストを2つ含むタプルを作ると、繰り返されるのはリストへのタグ付きポインタ、つまり`00000000000000000000000010000001`だけです。次のコードを考えます。
```erlang
L = [104, 101, 108, 108, 111],
T = {L, L}.
```
これは下図のようなメモリレイアウトになります。Tはアドレス136のboxedオブジェクトを指しており、そこにはこれがサイズ2のタプルであることを示すARITYVALヘッダーがあり、続く2つの要素はどちらもアドレス128にある同じリストLを指しています。
*図: 同じリストを共有するタプルT={L,L}のメモリレイアウト*
これは安上がりで、使用する領域もごくわずかなので都合がよい仕組みです。しかしこのタプルを別のプロセスに送ったり、何らかのIOを行ったり、**ディープコピー**と呼ばれる操作を行ったりすると、データ構造は展開されてしまいます。
例えばタプルTを別のプロセスP2に送ると（`P2 ! T`）、P2のヒープには、1つ目の要素が文字列の一方のコピーを指し、2つ目の要素がもう一方のコピーを指すタプルができ、使用する領域が倍になります。この結果は、後述する[メッセージ送信の節](#copied_message)で確認できます。
入れ子になった共有タプルがある場合、ディープコピーによるこの複製はネストの深さに応じて指数的に増えていきます。
高度に共有されたタームを展開させることで、あっという間にErlangノードを落とすこともできます。完全なコード例は、オンライン付録の`share.erl`を参照してください。
```erlang
-module(share).
-export([share/2, size/0]).
share(0, Y) -> {Y,Y};
share(N, Y) -> [share(N-1, [N|Y]) || _ <- Y].
size() ->
T = share:share(5,[a,b,c]),
{{size, erts_debug:size(T)},
{flat_size, erts_debug:flat_size(T)}}.
1> timer:tc(fun() -> share:share(10,[a,b,c]), ok end).
{1131,ok}
2> share:share(10,[a,b,c]), ok.
ok
3> byte_size(term_to_binary(share:share(10,[a,b,c]))), ok.
HUGE size (13695500364)
Abort trap: 6
```
共有タームのメモリサイズと、展開した場合のサイズは、`erts_debug:size/1`と`erts_debug:flat_size/1`という関数で計算できます。
```erlang
> share:size().
{{size,19386},{flat_size,94110}}
```
ほとんどのアプリケーションではこれは問題になりませんが、さまざまな場面で起こりうる問題として知っておくべきです。
ディープコピーは、IO、ETSテーブル、`binary_to_term`、そしてメッセージ送信で使われます。
{{< message >}}
ERTSは`--enable-sharing-preserving`という設定オプション付きでビルドすることができ、これによりVMはこうした場面で共有タームを検出し、保持するようになります。ただし共有がない通常のケースでメッセージ送信がわずかに遅くなるため、デフォルトでは有効になっていません。
これをデフォルトモードにすべきだという意見もあります。頻繁には起きないとしても、非常にまずい事態を防げるからです。Erlangをソースからビルドする方法は、[ERTSのビルドの章](../../appendix/building/#AP-BuildingERTS)を参照してください。
{{< /message >}}
それでは、メッセージ送信がどのように動くのかを、もう少し詳しく見ていきましょう。
### メッセージ送信
プロセスP1が別の（ローカルな）プロセスP2にメッセージMを送るとき、P1はまずMのフラットサイズを計算します。
そのうえで、ローカルスケジューラのコンテキストでヒープフラグメントを`heap_alloc`することで、そのサイズの新しいメッセージバッファを確保します。
`send.erl`（オンライン付録を参照）のコードを例にすると、`p1/1`での送信の直前、システムの状態はおおよそ次のようになります。
*図: p1/1実行中、送信直前のレジスタとメモリの状態*
ここでP1はP2へのメッセージMの送信を開始します。`erl_message.c`のコードは、まずMのフラットサイズ（この例では23ワード）を計算します[^1]。
そのうえで（SMPシステムでは）P2にロックをかけられて、かつP2のヒープに十分な空きがあれば、メッセージをP2のヒープにコピーします。
P2が実行中（または終了処理中）であるか、ヒープに十分な空きがない場合は、新しいヒープフラグメントが確保されます（サイズは`sizeof ErlHeapFragment - sizeof(Eterm) + 23*sizeof(Eterm)`）[^2]。初期化後は次のようになります。
```
erl_heap_fragment:
ErlHeapFragment* next; NULL
ErlOffHeap off_heap:
erl_off_heap_header* first; NULL
Uint64 overhead; 0
unsigned alloc_size; 23
unsigned used_size; 23
Eterm mem[1]; ?
... 22 free words
```
続いて、メッセージはヒープフラグメントの`mem`部分にコピーされ、`first`ポインタが更新されます（この図では、構造体のレイアウトに合わせてメモリアドレスが下方向に増えることに注意してください）。
*図: ヒープフラグメントへディープコピーされたメッセージ（タプルの2要素それぞれに、リストの複製ができる）*
どちらの場合でも、新しいmbox（`ErlMessage`）が確保され、受信側に対してロック（`ERTS_PROC_LOCK_MSGQ`）が取られ、ヒープ上または新しいヒープフラグメント内のメッセージがmboxにリンクされます。
```c
erl_mesg {
struct erl_mesg* next = NULL;
data: ErlHeapFragment *heap_frag = bp;
Eterm m[0] = message;
} ErlMessage;
```
そのmboxは受信側の受信キュー（`msg_inq`）にリンクされ、ロックが解放されます。
`msg_inq.last`は、キュー内の最後のメッセージの`next`フィールドを指していることに注意してください。新しいmboxがリンクされると、この`next`ポインタは新しいmboxを指すように更新され、`last`ポインタは新しいmboxの`next`フィールドを指すように更新されます。
### バイナリ
[型システムの章](../type_system/#CH-TypeSystem)で見たように、内部的にはバイナリには4種類あります。
そのうち3つ、**ヒープバイナリ**、**サブバイナリ**、**マッチコンテキスト**は、ローカルヒープに格納され、他のオブジェクトと同じようにガベージコレクタとメッセージ送信によって扱われ、必要に応じてコピーされます。
#### 参照カウント
一方、4つ目の種類である大きなバイナリ、すなわち**refcバイナリ**は、プロセスヒープの外側に部分的に格納され、参照カウントされます。
refcバイナリのペイロードは、バイナリアロケータが確保したメモリに格納されます。
そのペイロードへの小さな参照である`ProcBin`は、プロセスヒープに格納されます。この参照はメッセージ送信やGCによってコピーされますが、ペイロード自体には触れられません。
そのため、バイナリ全体をコピーする必要がなく、大きなバイナリを他のプロセスに送るのが比較的安上がりになります。
`ProcBin`を通じたrefcバイナリへの参照は、そのたびにバイナリの参照カウントを1つ増やします。
プロセスヒープ上のすべての`ProcBin`オブジェクトは、連結リストでつながっています。GCが走ると、このリストがたどられ、死んだ`ProcBin`ごとにバイナリの参照カウントが1つ減らされます。
refcバイナリの参照カウントが0になると、そのバイナリは解放されます。
大きなバイナリが参照カウントされ、送信やガベージコレクションでコピーされないのは大きな利点ですが、ガベージコレクションと参照カウントが混在する環境には1つ問題があります。
純粋な参照カウント方式の実装であれば、オブジェクトへの参照が死んだ瞬間に参照カウントは減り、参照カウントが0になった時点でオブジェクトは解放されます。
しかしERTSの混在環境では、参照カウントされたオブジェクトへの参照は、ガベージコレクションがその参照の死を検出するまで死んだことになりません。
つまり、大きい、あるいは巨大になりがちなバイナリが、すべての参照が死んだあとも長い間居座ることがあるということです。
バイナリはグローバルに確保されるため、すべてのプロセスからのすべての参照が死ぬ必要がある、つまりそのバイナリを見たことのあるすべてのプロセスがGCを行う必要がある点に注意してください。
残念ながら、GCの意味での「見た」という観点で、どのプロセスがそのバイナリを見たことがあるのかを、開発者が見極めるのは必ずしも簡単ではありません。
例えば、作業アイテムを受け取ってワーカーに振り分けるロードバランサーがあるとします。
[次のコード](#load_balancer)には、GCを行う必要のないループの例があります（完全な例はオンライン付録を参照してください）。
```erlang
loop(Workers, N) ->
receive
WorkItem ->
Worker = lists:nth(N+1, Workers),
Worker ! WorkItem,
loop(Workers, (N+1) rem length(Workers))
end.
```
このサーバーは、バイナリへの参照をつかんだままひたすら増やし続け、決して解放しないため、最終的にシステムメモリをすべて使い切ってしまいます。
この問題に気づいてさえいれば、直すのは簡単です。`loop`の各繰り返しで`garbage_collect`を呼ぶか、receiveに`after`節を加えて5秒おきくらいに呼べばよいのです（`after 5000 -> garbage_collect(), loop(Workers, N)`）。
#### サブバイナリとマッチング
バイナリの一部をマッチさせると、サブバイナリが得られます。
このサブバイナリは、実体のバイナリを指すポインタだけを含む小さな構造体です。バイナリの参照カウントは増えますが、追加で使う領域はごくわずかです。
もしマッチのたびにマッチした部分のコピーを新たに作るとしたら、領域と時間の両方でコストがかかります。
そのため、ほとんどの場合、バイナリに対してパターンマッチを行い、作業対象としてサブバイナリを得るというやり方が望ましいのです。
ただし困った状況もあります。例えば本のような巨大なファイルをメモリに読み込み、そこから章のような小さな部分をマッチさせて作業するとします。
すると、その章の処理が終わるまで、本の残り部分もまるごとメモリに保持されたままになるという問題が起きます。
これをファイルシステム上の多数の本に対して行い、例えばすべての本の序文を取り出したいとすると、序文の章だけでなく本1冊ずつがまるごとメモリに残ってしまいます。これは莫大なメモリ使用量につながりかねません。
大きなバイナリのごく一部だけが欲しく、その小さな部分をしばらく保持しておきたいとわかっている場合の解決策は、`binary:copy/1`を使うことです。
この関数は、その副作用、つまりサブバイナリを実体のバイナリから実際にコピーして取り出し、大きなバイナリへの参照を取り除くことで、うまくいけばガベージコレクトされるようにするためだけに使われます。
バイナリの構築とマッチングがどのように行われるかについては、[Erlangのドキュメント](http://www.erlang.org/doc/efficiency_guide/binaryhandling.html)にかなり踏み込んだ説明があります。
## その他の興味深いメモリ領域
### アトムテーブル
Erlangのアトムは、内部的には整数で表現される一意な識別子です。すべてのアトムは、**アトムテーブル**と呼ばれるグローバルな構造体に格納されます。
アトムテーブルは固定サイズの構造体であり、実行中のErlangシステムに存在できるアトムの数には上限があります（デフォルトで1,048,576個）。
大きな数に聞こえるかもしれませんが、不用意な使い方（とくに外部データから動的にアトムを生成する場合）はアトムの枯渇を招き、BEAM VM全体をクラッシュさせます。夜中に思いがけずレゴブロックを踏んでしまうのと同じくらい、愉快とは言えない出来事です。
アトムテーブルの各エントリには、アトムに関するメタデータが含まれます。文字列表現（アトムそのもののテキスト）、ランタイムシステムが使う一意な内部識別子、そして参照カウントやモジュール・関数での使用状況といった追加情報です。
Erlangは、3つの主要なメモリアロケータ種類を通じてアトムを管理しています。
- `atom_text`：アトムの文字列表現を格納します。この領域には、アトムの実際のテキストが保存されます。
- `atom_tab`：アトムテーブル自体、つまり高速な検索のためのハッシュテーブル構造を格納します。
- `atom_entry`：各アトムのメタデータ（内部表現、使用回数など）のためのメモリを確保します。
アトムはガベージコレクトされません。一度作られたアトムは、VMがシャットダウンするまで残り続けます。
この設計上の判断は実装を単純化し（検索性能も高めます）ますが、リスクも伴います。制御されないアトム生成（`list_to_atom/1`のような関数を通じた動的なアトム生成が典型的です）は、アトムテーブルの枯渇につながりかねません。
アトムの上限に達すると、新しいアトムを作ろうとしたときにランタイムエラーが発生し、ノードが落ちることもあります。
問題が起きやすいのは、ユーザー提供のデータを直接アトムに変換する、信頼できない大量の外部入力をパースする、ループや再帰関数の中でアトムを繰り返し生成するなど、アトムが不用意に、あるいは動的に作られる場面です。
こうした状況はアトムテーブルの急速な増大につながり、アトムの上限を使い切って深刻なシステム障害を招きかねません。
これを避けるには次のようにします。
- アトムに変換する前に、ユーザー入力を必ず検証するか許可リストで絞り込みます。
- できる限り既存のアトムを使い、動的な識別子がどうしても必要ならバイナリや文字列を優先します。
- ObserverのようなツールやAtomsに関する組み込み関数を使って、アトムテーブルの使用状況を定期的に監視します。
- **アトム数**（`erlang:system_info(atom_count)`）：現在ロードされている一意なアトムの数。
- **アトムメモリ**（`erlang:memory(atom)`）：オーバーヘッドを含む、アトムが使う総バイト数。
- **アトム使用メモリ**（`erlang:memory(atom_used)`）：実際のアトム文字列が使うバイト数のみ。
Erlangシェルから簡単に確認するだけで、手早く状況がわかります。
```erlang
1> erlang:system_info(atom_count).
34319
2> erlang:system_info(atom_limit).
1048576
3> erlang:memory(atom).
336049
4> erlang:memory(atom_used).
324520
```
アトムの上限に達してしまった場合、実践的な解決策が2つあります。
**アトムテーブルのサイズを増やす**（ただし、これは一般に短期的な応急処置であり、アトムの適切な扱いに代わるものではありません）。
```shell
erl +t
```
**アプリケーションを設計し直す**：典型的にはバイナリや文字列、整数の識別子を代わりに使うことで、アトムの無制限な生成を避けます。
このように、アトムとその管理には注意が必要です。誤った使い方は安定性の問題を引き起こしますが、正しく扱えば、システム全体で静的で既知のキーや識別子を参照する、きわめて効率的な手段であり続けます。
アトム枯渇のリスクなしに文字列を安全にアトムへ変換するために、Erlangは`list_to_existing_atom/1`関数を用意しています。
この関数は、そのアトムがすでに存在する場合にのみ成功します。この関数で新しいアトムを作ろうとすると、例外が発生します。
```erlang
1> list_to_existing_atom("Hello").
** exception error: bad argument
in function list_to_existing_atom/1
called as list_to_existing_atom("Hello")
*** argument 1: not an already existing atom
2> list_to_existing_atom("true").
true
```
### コード領域
もう1つの重要なメモリ領域が、コンパイル済みErlangモジュールがロードされる**コード領域**です。
Erlangモジュールは、一度コンパイルされるとこのコード領域にロードされ、Erlangランタイムシステム内で動くすべてのプロセスの間で共有されます。
コード領域は基本的に静的で永続的です。モジュールは、（ホットコードロードによって）明示的にアンロードまたは置き換えられない限り、ロードされたままだからです。
`l(Module)`や`code:load_file(Module)`のような関数でモジュールをロードまたは再ロードすると、古いコードはすぐには削除されず、どのプロセスからも参照されなくなるまで「古い」バージョンとして保持されます。
Erlangは各モジュールについて、同時に2つのバージョンを維持します。これにより、実行中のプロセスを中断させることなく、安全にアップグレードできます。
数値やアトム、バイナリといったErlangコード内で定義された定数は、モジュールのコードセグメント内にある定数プールに格納されます。
これらの定数は1つのモジュール内では一度しか格納されないため、メモリ使用の面で効率的です。
しかし、メッセージ送信やETSテーブルへの挿入など、モジュールの外で定数が使われる場合は、受け取る側のプロセスのヒープにコピーされ、全体のメモリ使用量を大きく増やすことがあります。
コードのメモリ使用量を監視し管理することは、とくにホットコードアップグレードを頻繁に行う長時間稼働のシステムでは欠かせません。
`code:all_loaded/0`のような組み込み関数でロード済みモジュールとその状態を調べられ、`erlang:memory(code)`でロード済みモジュールとその定数による総メモリ使用量を監視できます。
```erlang
1> erlang:memory(code).
6378630
```
[^1]: ここではトレーシングを無視しています。トレーシングを行うと、メッセージのサイズにトレーストークンが加わり、常にヒープフラグメントを使うことになります。
[^2]: `-sizeof(Eterm)`という項は、`ErlHeapFragment`の`mem`がすでに1つの`Eterm`分のサイズを持っていることに由来します。