Loading article…
コンピューティング アーキテクチャのスタックは、後入れ先出し (LIFO)方式でデータが追加または削除されるメモリ領域です。
最近のほとんどのコンピュータ システムでは、各スレッドにスタックと呼ばれるメモリの予約領域があります。関数が実行されると、関数はローカル状態データの一部をスタックの先頭に追加します。関数が終了すると、そのデータをスタックから削除する役割を担います。少なくとも、スレッドのスタックは、呼び出し元によって提供された戻りアドレスの場所を保存して、戻りステートメントが正しい場所に戻れるようにするために使用されます。
スタックは、現在アクティブな関数にローカルな固定長の変数を格納するためによく使用されます。プログラマーは、さらに、可変長のローカル データを格納するためにスタックを明示的に使用することもできます。メモリ領域がスレッドのスタック上にある場合、そのメモリはスタックに割り当てられた、つまりスタック ベースのメモリ割り当て (SBMA) と呼ばれます。これは、ヒープ ベースのメモリ割り当て(HBMA) とは対照的です。SBMA は、関数呼び出しスタックと密接に結合されることがよくあります。
利点と欠点
データは後入れ先出し方式で追加および削除されるため、スタックベースのメモリ割り当ては非常に単純で、通常、Cなどのヒープベースのメモリ割り当て (動的メモリ割り当てとも呼ばれます)よりもはるかに高速です。
malloc
もう 1 つの特徴は、関数の終了時にスタック上のメモリが自動的に、かつ非常に効率的に再利用されることです。これは、データが不要になった場合にプログラマーにとって便利です。[1] ( longjmp が呼び出しが発生する前のポイントに移動された場合にも同じことが当てはまりますalloca)。ただし、データを何らかの形式で保持する必要がある場合は、関数が終了する前にスタックからヒープにコピーする必要があります。したがって、スタック ベースの割り当ては、一時データや、現在の関数が終了した後に不要になったデータに適しています。
スレッドに割り当てられたスタック サイズは、一部の小型 CPU では数バイト程度にまで小さくなることがあります。使用可能な量よりも多くのメモリをスタックに割り当てると、スタック オーバーフローによるクラッシュが発生する可能性があります。これは、 を使用する関数が通常インライン化されない理由でもあります。[2]このような関数がループにインライン化されると、呼び出し元はスタック使用量の予期しない増加に悩まされ、オーバーフローが発生する可能性が高くなります。
alloca
スタックベースの割り当ては、パフォーマンス上の軽微な問題を引き起こすこともあります。スタック フレームのサイズが可変になるため、スタック ポインタとフレーム ポインタの両方を管理する必要が生じます (固定サイズのスタック フレームでは、スタック フレーム ポインタに各フレームのサイズを掛け合わせるため、スタック ポインタは冗長になります)。これは通常、 や を呼び出すよりmallocもfreeはるかにコストがかかりません。特に、現在の関数に と の両方の呼び出しalloca(可変長のローカル データを含むブロック) が含まれている場合、現在の関数が終了するまで現在のスタック フレームを増やそうとする alloca の試みと、可変長のローカル変数をスタック フレーム内の同じ場所に配置するコンパイラの必要性との間で競合が発生します。この競合は通常、 の各呼び出しごとにヒープ ストレージの別のチェーンを作成することで解決されますalloca。[3] チェーンは、各割り当てが発生するスタックの深さを記録し、alloca任意の関数で を後続で呼び出すと、このチェーンが現在のスタックの深さまで切り詰められ、最終的に (ただしすぐには) このチェーン上のストレージが解放されます。 を 0 の引数で呼び出すと、allocaそのようなメモリをこれ以上割り当てずにメモリの解放をトリガーすることもできます。allocaとローカル変数ストレージの間にこの競合があるため、 を使用することはallocaを使用することよりも効率的ではない可能性がありますmalloc。
システムインターフェース
多くのUnix 系システムやMicrosoft Windows では、allocaヒープベースの と同様の方法でスタック メモリを動的に割り当てるために と呼ばれる関数を実装しています。コンパイラは通常、可変長配列のmalloc処理方法と同様に、スタック ポインタを操作するインライン命令に変換します。[4]メモリを明示的に解放する必要はありませんが、スタック オーバーフローによる未定義の動作が発生するリスクがあります。[5]この関数は、 32/V (1978)の頃から Unix システムに存在していましたが、標準 CやPOSIX標準の一部ではありません。
Microsoft Windows には、割り当てサイズが大きすぎる場合にヒープに割り当て、スタック オーバーフロー エラーを報告する とalloca呼ばれるのより安全なバージョンが存在します。 を使用する必要がある。[6] gnulib は同等のインターフェイスを提供しますが、オーバーフロー時に SEH 例外をスローする代わりに、大きすぎるサイズが検出されると に委譲します。[7]同様の機能は、glibc での の使用など、手動のアカウンティングとサイズ チェックを使用してエミュレートできます。[8]_malloca_freea mallocalloca_account
x86などの一部のプロセッサ ファミリには、現在実行中のスレッドのスタックを操作するための特別な命令があります。RISC-V、PowerPC、MIPSなどの他のプロセッサ ファミリには明示的なスタック サポートはありませんが、代わりに規則に依存し、スタック管理をオペレーティング システムのアプリケーション バイナリ インターフェイス(ABI) に委任します。
自動VLA
さらに、CバージョンC99以降（C11以降はオプション）では、関数内のスタック上に配列を自動的に作成することが可能であり、これは自動VLA（可変長配列）として知られています。[9]
void f ( int arrayLength ) { int b [ arrayLength ]; // auto VLA - この配列の長さは、関数の呼び出し/スタック生成時に設定されます。for ( int i = 0 ; i < arrayLength ; i ++ ) b [ i ] = 1 ; // この関数の終了時には、b[] はスタック フレーム内にあり、関数が終了すると消えるため、free() を明示的に呼び出す必要はありません。}
参照
参考文献
- ^ 「Alloca の利点」。GNU C ライブラリ。
- ^ 「インライン」。GNUコンパイラ コレクション (GCC) の使用。
- ^ 「Alloca.c ソースコード [libiberty/Alloca.c] - Codebrowser」。
- ^ – Linuxプログラマーズマニュアル– ライブラリ関数
- ^ 「なぜ alloca() の使用は良い方法とはみなされないのか?」。stackoverflow.com。2016年 1 月 5 日閲覧。
- ^ "_malloca". Microsoft CRT ドキュメント。
- ^ "gnulib/malloca.h". GitHub . 2019年11月24日閲覧。
- ^ "glibc/include/alloca.h". Beren Minor のミラー。2019 年 11 月 23 日。
- ^ 「ISO C 99 定義」(PDF) 。 2022年4月10日閲覧。