メモリマップファイル

メモリマップファイルは、ファイルまたはファイルのようなリソースの一部とバイト単位で直接相関関係が割り当てられた仮想メモリ^[1]のセグメントです。このリソースは通常、物理的にディスク上に存在するファイルですが、デバイス、共有メモリオブジェクト、またはオペレーティングシステムがファイル記述子を介して参照できるその他のリソースである場合もあります。ファイルとメモリ空間の間にこの相関関係が存在すると、アプリケーションはマップされた部分をプライマリメモリであるかのように扱うことができます。

初期（ 1969年頃）^[2]の実装としては、DEC-20のTOPS-20オペレーティングシステム上のPMAPシステムコール^[3]があり、これはSoftware HouseのSystem-1022データベースシステムで使用されていた機能である。^[4]

SunOS 4 ^[5]では、 Unixのが導入されmmap、プログラムが「ファイルをメモリにマップ」できるようになりました。^[1]

TOPS-20 の PMAP がリリースされてから 20 年後、Windows NT にGrowable Memory-Mapped Files (GMMF) が導入されました。

「CreateFileMapping関数にはサイズを渡す必要がある」ため、ファイルサイズの変更は容易には対応できないため、GMMF APIが開発されました。^{[6] [7]} GMMFを使用するには、ファイルサイズが増加する最大値を宣言する必要がありますが、未使用のスペースは無駄になりません。

ファイルをメモリ マッピングする利点は、特に大きなファイルで使用する場合、I/O パフォーマンスが向上することです。小さなファイルの場合、メモリ マップはページ サイズ (ほとんどの場合 4 KiB) に合わせて常に調整されるため、メモリ マップされたファイルはスラック スペース^[8]の無駄が生じる可能性があります。したがって、5 KiB のファイルは 8 KiB を割り当て、3 KiB が無駄になります。メモリ マップされたファイルへのアクセスは、直接の読み取りおよび書き込み操作を使用するよりも高速です。これには 2 つの理由があります。第 1 に、システム コールは、プログラムのローカル メモリへの単純な変更よりも桁違いに低速です。第 2 に、ほとんどのオペレーティング システムでは、マップされたメモリ領域は実際にはカーネルのページ キャッシュ(ファイル キャッシュ)であるため、ユーザー空間にコピーを作成する必要はありません。

アプリケーション レベルのメモリ マップ ファイル操作の中には、物理​​ファイル操作よりもパフォーマンスが優れているものもあります。アプリケーションは、ファイルの先頭からシークしたり、編集した内容全体を一時的な場所に書き直したりするのではなく、ファイル内のデータに直接かつその場でアクセスして更新できます。メモリ マップ ファイルはページ単位で内部的に処理されるため、線形ファイル アクセス (フラット ファイルデータ ストレージや構成ファイルなどで見られる) では、新しいページ境界を越えるときにのみディスク アクセスが必要になり、1 回の操作でファイルのより大きなセクションをディスクに書き込むことができます。

メモリマップされたファイルの利点として考えられるのは、「遅延読み込み」です。これにより、非常に大きなファイルでも RAM の使用量が少なくなります。使用可能なメモリ量よりも大幅に大きいファイルの内容全体をロードしようとすると、オペレーティング システムがディスクからメモリに読み込み、同時にメモリからディスクにページを書き戻すため、深刻なスラッシングが発生する可能性があります。メモリ マッピングでは、ページ ファイルを完全にバイパスできるだけでなく、プログラムで使用されるデマンド ページングと同様に、データの編集時にページ サイズの小さいセクションをロードすることもできます。

メモリマッピングプロセスは、ページファイルの処理を担当する同じサブシステムである仮想メモリマネージャによって処理されます。メモリマップファイルは、一度に1ページ全体がメモリにロードされます。ページサイズは、最大のパフォーマンスを得るためにオペレーティングシステムによって選択されます。ページファイル管理は仮想メモリシステムの最も重要な要素の1つであるため、ファイルのページサイズのセクションを物理メモリにロードすることは、通常、非常に高度に最適化されたシステム機能です。^[9]

メモリマップ ファイルには 2 種類あります。

永続ファイルはディスク上のソースファイルに関連付けられています。最後のプロセスが終了すると、データはディスク上のソースファイルに保存されます。これらのメモリマップファイルは、非常に大きなソースファイルを扱うのに適しています。^[10]

非永続ファイルはディスク上のファイルに関連付けられていません。最後のプロセスがファイルの処理を終了すると、データは失われます。これらのファイルは、プロセス間通信 (IPC) 用の共有メモリを作成するのに適しています。^[10]

メモリマップファイルI/Oを選択する主な理由はパフォーマンスです。しかし、トレードオフもあります。標準I/Oアプローチは、システムコールのオーバーヘッドとメモリコピーのためにコストがかかります。メモリマップアプローチは、データブロックがページキャッシュにロードされているが、プロセスの仮想メモリスペースにまだマップされていない場合に、マイナーページフォールトが発生するというコストがかかります。状況によっては、メモリマップファイルI/Oは標準ファイルI/Oよりも大幅に遅くなることがあります。^[11]

メモリマップ ファイルのもう 1 つの欠点は、特定のアーキテクチャのアドレス空間に関連しています。アドレス可能な空間より大きいファイルは、一度にマップできる部分のみを持つことができるため、読み取りが複雑になります。たとえば、 Intel のIA-32などの32 ビットアーキテクチャでは、ファイルの 4 GiB以下の部分のみを直接アドレス指定できます。個々のプログラムで使用できるアドレス可能な空間はさらに少なく、通常はオペレーティング システム カーネルに応じて 2 ～ 3 GiB の範囲です。ただし、この欠点は、最新の64 ビットアーキテクチャでは事実上解消されています。

mmap は、Linux を含む多くのオペレーティング システムでページ フォールトを処理するコアの数に上限があるため、標準的なファイル I/O 手段よりもスケーラビリティが低くなる傾向があります。最新のNVM Express SSD などの非常に高速なデバイスでは、オーバーヘッドが大きな問題になる可能性があります。^[12]

マップされたメモリにアクセスしているときに、基礎となるファイルで発生した I/O エラー (リムーバブル ドライブが取り外されている、光学メディアが取り出されている、書き込み時にディスクがいっぱいであるなど) は、POSIX では SIGSEGV/SIGBUS シグナルとして、Windows では EXECUTE_IN_PAGE_ERROR 構造化例外としてアプリケーションに報告されます。マップされたメモリにアクセスするすべてのコードは、通常メモリへのアクセス時には発生しないこれらのエラーを処理できるように準備する必要があります。

MMUを備えたハードウェア アーキテクチャのみがメモリ マップ ファイルをサポートできます。MMU のないアーキテクチャでは、マップ要求が行われたときにオペレーティング システムがファイル全体をメモリにコピーできますが、ファイルのほんの一部しかアクセスされない場合、これは非常に無駄が多く、遅くなります。また、使用可能なメモリに収まるファイルに対してのみ機能します。

おそらく、メモリマップファイルの最も一般的な用途は、ほとんどの最新のオペレーティングシステム（Microsoft WindowsやUnix系システムを含む）のプロセスローダーです。プロセスが開始されると、オペレーティングシステムはメモリマップファイルを使用して、実行可能ファイルとロード可能なモジュールをメモリに読み込み、実行します。ほとんどのメモリマッピングシステムでは、デマンドページングと呼ばれる手法が使用されています。この手法では、ファイルはサブセット（1ページずつ）で物理メモリにロードされ、そのページが実際に参照された場合にのみロードされます。^[13]実行可能ファイルの特定のケースでは、これによりOSは、実際に実行する必要があるプロセスイメージの部分のみを選択的にロードできます。

メモリマップ ファイルのもう 1 つの一般的な用途は、複数のプロセス間でメモリを共有することです。最近の保護モードのオペレーティング システムでは、プロセスは、別のプロセスが使用するために割り当てられたメモリ領域にアクセスすることはできません (プログラムがアクセスしようとすると、無効なページ フォールトまたはセグメンテーション違反が発生します)。メモリを安全に共有するための手法は多数ありますが、メモリマップ ファイル I/O は最も一般的な手法の 1 つです。2 つ以上のアプリケーションが同時に 1 つの物理ファイルをメモリにマップし、このメモリにアクセスできます。たとえば、Microsoft Windows オペレーティング システムでは、アプリケーションがシステムのページ ファイル自体の共有セグメントをメモリマップし、このセクションを介してデータを共有するためのメカニズムが提供されています。

最近のオペレーティングシステムやランタイム環境のほとんどは、何らかの形でメモリマップされたファイルアクセスをサポートしています。ファイル記述子、ファイル内の開始位置、長さを指定してファイルのマッピングを作成する関数 mmap() ^{[14] は}POSIX仕様の一部であるため、UNIX、Linux、Mac OS X ^{[15] 、} OpenVMSなどのさまざまな POSIX 準拠システムがメモリマッピングファイルの共通メカニズムをサポートしています。Microsoft Windows オペレーティングシステムも、 CreateFileMapping()などのこの目的のためのAPI関数のグループをサポートしています。^[16]

Microsoft Windows および POSIX 準拠プラットフォーム用のメモリマップ ファイルの無料のポータブル実装には、次のものがあります。

• Boost.Interprocess、^[17] Boost C++ライブラリ
• Boost.Iostreams、^[18] Boost C++ライブラリにも収録
• FMストリーム^[19]
• Cpp-mmf ^[20]

Javaプログラミング言語は、 などのメモリマップファイルにアクセスするためのクラスとメソッドを提供しますFileChannel。

Dプログラミング言語は標準ライブラリ（std.mmfileモジュール）でメモリマップファイルをサポートしています。^[21]

Ruby には、メモリマップされたファイル オブジェクトを実装する Mmap という gem (ライブラリ) があります。

Pythonバージョン1.6以降、標準ライブラリにmmapモジュールが含まれています。 ^{[22]モジュールの詳細は、ホストプラットフォームが}WindowsかUnix系かによって異なります。

Perlでは、 Sys::Mmap ^[23]やFile::Map [ ^24]など、CPAN上にメモリマッピングファイル用のモジュールがいくつかあります。

Microsoft .NET ランタイムでは、P/Invoke を使用してWindows API経由でメモリマップファイルを直接使用できます。メモリマップファイルへのマネージドアクセス (P/Invoke は不要) は、ランタイムのバージョン 4 で導入されました (「メモリマップファイル」を参照)。以前のバージョンでは、マネージド API を提供するサードパーティライブラリがあります。^[25]

PHP は、file_get_contents() などの多くのネイティブ ファイル アクセス関数でメモリ マッピング手法をサポートしていましたが、5.3 ではこれが削除されました (リビジョン ログを参照)。

R プログラミング言語の場合、CRAN に bigmemory というライブラリが存在します。これは Boost ライブラリを使用し、メモリマップされた配列を R で直接提供します。パッケージ ff は、メモリマップされたベクトル、行列、配列、およびデータ フレームを提供します。

J プログラミング言語は、少なくとも2005 年からメモリ マップ ファイルをサポートしています。これには、ボックス配列データと単一データ型ファイルのサポートが含まれます。サポートは 'data/jmf' からロードできます。J の Jdb および JD データベース エンジンは、列ストアにメモリ マップ ファイルを使用します。

Juliaプログラミング言語は、標準ライブラリ内のモジュールを通じてメモリマップされたバイナリファイルのI/Oをサポートしています。 ^[26]Mmap