Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 19007] ファイルの概要

このコミットは、Goコンパイラのコード生成部分、具体的にはcmd/gc(Goコンパイラ)内のggen.cファイルにおけるスタックフレームのゼロ初期化ロジックに関する最適化とバグ修正です。不要なメモリ領域のゼロ初期化を防ぐことを目的としています。

コミット

commit 47acf167098639ce182417548669a4776507f7b7
Author: Keith Randall <khr@golang.org>
Date:   Wed Apr 2 09:17:42 2014 -0700

    cmd/gc: Don't zero more than we need.
    
    Don't merge with the zero range, we may
    end up zeroing more than we need.
    
    LGTM=rsc
    R=rsc
    CC=golang-codereviews
    https://golang.org/cl/83430044

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/47acf167098639ce182417548669a4776507f7b7

元コミット内容

cmd/gc: Don't zero more than we need.

このコミットは、Goコンパイラがスタックフレームをゼロ初期化する際に、必要以上のメモリ領域をゼロにしないようにする変更です。既存のゼロ初期化範囲とのマージロジックに問題があり、それが過剰なゼロ初期化を引き起こす可能性があったため、その問題を修正しています。

変更の背景

Go言語では、セキュリティと予測可能性のために、新しく確保されたメモリ(特にスタック上のローカル変数)は自動的にゼロ値で初期化されるという重要な特性があります。これにより、以前の関数の実行によって残された「ゴミ」データが新しい変数に影響を与えることを防ぎ、未初期化のメモリを読み込むことによるセキュリティ脆弱性や未定義の動作を防ぎます。

cmd/gc(Goコンパイラ)のコード生成フェーズでは、関数のスタックフレームが設定される際に、このゼロ初期化処理が行われます。コンパイラは、効率を上げるために、ゼロ初期化が必要な複数のメモリ領域を可能な限り連続した大きなブロックとして処理しようとします。これは、defframe関数内でlohiという変数を使ってゼロ初期化の範囲を管理し、隣接する、またはオーバーラップするゼロ初期化要求をマージすることで実現されます。

しかし、このマージロジックに不具合がありました。特定の条件下で、まだゼロ初期化の範囲が確立されていない、または適切にリセットされていないにもかかわらず、マージ処理が実行されてしまうことがありました。これにより、コンパイラが意図しない、より広い範囲のメモリをゼロ初期化してしまう可能性がありました。これはパフォーマンスの低下につながるだけでなく、理論的にはデバッグの際に混乱を招く可能性もありました。

このコミットは、この過剰なゼロ初期化を防ぎ、コンパイラが厳密に必要とされるメモリ領域のみをゼロ初期化するように修正することを目的としています。

前提知識の解説

  1. Goコンパイラ (cmd/gc): Go言語の公式コンパイラであり、Goソースコードを機械語に変換する役割を担っています。cmd/gcは、フロントエンド(構文解析、型チェックなど)からバックエンド(コード生成、最適化など)まで、コンパイルプロセスの大部分をカバーします。

  2. ggen.c: Goコンパイラのソースコードの一部で、ジェネリックなコード生成(generic code generation)を担当するC言語ファイルです。Goコンパイラは、初期の段階ではC言語で書かれており、特にアセンブリコードの生成やスタックフレームの管理といった低レベルな処理はC言語で実装されていました。このファイルには、特定のアーキテクチャに依存しない、または共通のコード生成ロジックが含まれています。

  3. defframe 関数: ggen.c(および各アーキテクチャ固有の*g/ggen.cファイル、例: 6g/ggen.cはamd64、8g/ggen.cはarm)内に存在する関数で、Go関数のスタックフレームを設定するためのアセンブリコードを生成します。これには、ローカル変数のためのスペースの確保、レジスタの保存/復元、そして重要な「スタックフレームのゼロ初期化」が含まれます。

  4. スタックフレームとゼロ初期化: 関数が呼び出されると、その関数が使用するローカル変数、引数、リターンアドレスなどを格納するためのメモリ領域がスタック上に確保されます。これを「スタックフレーム」と呼びます。Goでは、このスタックフレーム内の新しいメモリ領域(特にポインタを含む可能性のある領域)は、セキュリティ上の理由から自動的にゼロ値で初期化されます。これにより、以前の関数の実行によって残された機密情報や無効なポインタが、新しい変数に誤って読み込まれることを防ぎます。

  5. lohi 変数: defframe関数内で、スタックフレームのゼロ初期化が必要な範囲を管理するために使用される変数です。

    • lo (low offset): ゼロ初期化が必要なメモリ範囲の開始オフセット(スタックフレームのベースからの相対位置)。
    • hi (high offset): ゼロ初期化が必要なメモリ範囲の終了オフセット。 コンパイラは、これらの変数を使って、複数のゼロ初期化要求を一つの連続した範囲にマージしようとします。
  6. widthreg / widthptr:

    • widthreg: レジスタの幅(バイト単位)。例えば、64ビットアーキテクチャでは8バイト。
    • widthptr: ポインタの幅(バイト単位)。これも通常はアーキテクチャのワードサイズに依存し、64ビットアーキテクチャでは8バイト。 これらの定数は、メモリのアライメントやオフセット計算に使用されます。

技術的詳細

このコミットの核心は、defframe関数内のゼロ初期化範囲のマージロジックの修正です。defframeは、関数のスタックフレームを構築する際に、ゼロ初期化が必要な変数を特定し、それらのメモリ領域をゼロにするための命令を生成します。

ゼロ初期化の範囲は、lohiという変数によって管理されます。コンパイラは、スタック上の変数を処理する際に、その変数がゼロ初期化を必要とする場合、既存のゼロ初期化範囲(loからhiまで)とマージできるかどうかを判断します。マージできると判断された場合、loの値を更新して、より広い範囲をカバーするようにします。

元のコードでは、マージの条件が以下のようになっていました(src/cmd/6g/ggen.cの場合):

if(n->xoffset + n->type->width >= lo - 2*widthptr) {
    // merge with range we already have
    lo = n->xoffset;
    continue;
}

そして、src/cmd/8g/ggen.cの場合:

if(n->xoffset + n->type->width == lo - 2*widthptr) {
    // merge with range we already have
    lo = n->xoffset;
    continue;
}

この条件は、「現在の変数nのメモリ領域が、既存のゼロ初期化範囲loの近くにあるか、またはそれに隣接しているか」をチェックしています。lo - 2*widthptrのようなオフセットは、アライメントやパディングを考慮したものです。

問題は、lohiがまだ有効なゼロ初期化範囲を示していない(例えば、初期状態や、前のゼロ初期化範囲が既に処理されてリセットされた後など)にもかかわらず、この条件が真になってしまう可能性があったことです。具体的には、lohiが同じ値(例えば、スタックフレームの初期オフセット)に設定されている場合、つまりゼロ初期化範囲が実質的に「空」である場合でも、上記の条件が満たされてしまい、lon->xoffsetに更新されてしまうことがありました。これにより、本来マージすべき既存の範囲がないにもかかわらず、マージ処理が実行され、結果として必要以上に広い範囲がゼロ初期化されてしまうというバグがありました。

このコミットでは、この問題を解決するために、マージ条件にlo != hiというチェックを追加しています。

コアとなるコードの変更箇所

src/cmd/6g/ggen.c

--- a/src/cmd/6g/ggen.c
+++ b/src/cmd/6g/ggen.c
@@ -45,7 +45,7 @@ defframe(Prog *ptxt)
 		if(n->type->width % widthreg != 0 || n->xoffset % widthreg != 0 || n->type->width == 0)
 			fatal("var %lN has size %d offset %d", n, (int)n->type->width, (int)n->xoffset);
 
-		if(n->xoffset + n->type->width >= lo - 2*widthptr) {
+		if(lo != hi && n->xoffset + n->type->width >= lo - 2*widthptr) {
 			// merge with range we already have
 			lo = n->xoffset;
 			continue;

src/cmd/8g/ggen.c

--- a/src/cmd/8g/ggen.c
+++ b/src/cmd/8g/ggen.c
@@ -42,7 +42,7 @@ defframe(Prog *ptxt)
 			fatal("needzero class %d", n->class);
 		if(n->type->width % widthptr != 0 || n->xoffset % widthptr != 0 || n->type->width == 0)
 			fatal("var %lN has size %d offset %d", n, (int)n->type->width, (int)n->xoffset);
-		if(n->xoffset + n->type->width == lo - 2*widthptr) {
+		if(lo != hi && n->xoffset + n->type->width == lo - 2*widthptr) {
 			// merge with range we already have
 			lo = n->xoffset;
 			continue;

コアとなるコードの解説

変更は両方のファイルで非常に似ており、既存のマージ条件の前に lo != hi && という条件が追加されています。

  • lo != hi: この新しい条件は、ゼロ初期化の範囲loからhiが実際に「非空」である場合にのみ、マージ処理を続行することを保証します。
    • もしlo == hiであれば、それは現在のゼロ初期化範囲がまだ設定されていないか、または既に処理されてリセットされた状態であることを意味します。このような場合、マージすべき既存の範囲は存在しないため、マージ処理はスキップされます。
    • これにより、コンパイラは、ゼロ初期化範囲が実際に存在し、かつ現在の変数とマージする意味がある場合にのみ、loの値を更新するようになります。

このシンプルな変更により、コンパイラが不必要に広いメモリ領域をゼロ初期化してしまうというバグが修正され、コード生成の効率が向上します。特に、スタックフレームのセットアップにおいて、厳密に必要とされるメモリ領域のみがゼロ初期化されるようになり、コンパイラが生成するコードの品質とパフォーマンスが改善されます。

関連リンク

参考にした情報源リンク

  • Go言語の公式ドキュメント
  • Goコンパイラのソースコード (特に src/cmd/gc ディレクトリ)
  • Go言語のスタックフレームとメモリ管理に関する一般的な知識
  • Goコンパイラの内部構造に関するコミュニティの議論やブログ記事 (具体的なURLは割愛しますが、一般的な知識として参照しました)
  • Go言語のコミット履歴とコードレビューシステム (Gerrit)
I have generated the detailed explanation in Markdown format, following all the specified instructions and chapter structure. I have explained the background, prerequisites, technical details, and the core code changes. I have also included the relevant links.
```# [インデックス 19007] ファイルの概要

このコミットは、Goコンパイラのコード生成部分、具体的には`cmd/gc`(Goコンパイラ)内の`ggen.c`ファイルにおけるスタックフレームのゼロ初期化ロジックに関する最適化とバグ修正です。不要なメモリ領域のゼロ初期化を防ぐことを目的としています。

## コミット

commit 47acf167098639ce182417548669a4776507f7b7 Author: Keith Randall khr@golang.org Date: Wed Apr 2 09:17:42 2014 -0700

cmd/gc: Don't zero more than we need.

Don't merge with the zero range, we may
end up zeroing more than we need.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/83430044

## GitHub上でのコミットページへのリンク

[https://github.com/golang/go/commit/47acf167098639ce182417548669a4776507f7b7](https://github.com/golang/go/commit/47acf167098639ce182417548669a4776507f7b7)

## 元コミット内容

`cmd/gc: Don't zero more than we need.`

このコミットは、Goコンパイラがスタックフレームをゼロ初期化する際に、必要以上のメモリ領域をゼロにしないようにする変更です。既存のゼロ初期化範囲とのマージロジックに問題があり、それが過剰なゼロ初期化を引き起こす可能性があったため、その問題を修正しています。

## 変更の背景

Go言語では、セキュリティと予測可能性のために、新しく確保されたメモリ(特にスタック上のローカル変数)は自動的にゼロ値で初期化されるという重要な特性があります。これにより、以前の関数の実行によって残された「ゴミ」データが新しい変数に影響を与えることを防ぎ、未初期化のメモリを読み込むことによるセキュリティ脆弱性や未定義の動作を防ぎます。

`cmd/gc`(Goコンパイラ)のコード生成フェーズでは、関数のスタックフレームが設定される際に、このゼロ初期化処理が行われます。コンパイラは、効率を上げるために、ゼロ初期化が必要な複数のメモリ領域を可能な限り連続した大きなブロックとして処理しようとします。これは、`defframe`関数内で`lo`と`hi`という変数を使ってゼロ初期化の範囲を管理し、隣接する、またはオーバーラップするゼロ初期化要求をマージすることで実現されます。

しかし、このマージロジックに不具合がありました。特定の条件下で、まだゼロ初期化の範囲が確立されていない、または適切にリセットされていないにもかかわらず、マージ処理が実行されてしまうことがありました。これにより、コンパイラが意図しない、より広い範囲のメモリをゼロ初期化してしまう可能性がありました。これはパフォーマンスの低下につながるだけでなく、理論的にはデバッグの際に混乱を招く可能性もありました。

このコミットは、この過剰なゼロ初期化を防ぎ、コンパイラが厳密に必要とされるメモリ領域のみをゼロ初期化するように修正することを目的としています。

## 前提知識の解説

1.  **Goコンパイラ (`cmd/gc`)**:
    Go言語の公式コンパイラであり、Goソースコードを機械語に変換する役割を担っています。`cmd/gc`は、フロントエンド(構文解析、型チェックなど)からバックエンド(コード生成、最適化など)まで、コンパイルプロセスの大部分をカバーします。

2.  **`ggen.c`**:
    Goコンパイラのソースコードの一部で、ジェネリックなコード生成(generic code generation)を担当するC言語ファイルです。Goコンパイラは、初期の段階ではC言語で書かれており、特にアセンブリコードの生成やスタックフレームの管理といった低レベルな処理はC言語で実装されていました。このファイルには、特定のアーキテクチャに依存しない、または共通のコード生成ロジックが含まれています。

3.  **`defframe` 関数**:
    `ggen.c`(および各アーキテクチャ固有の`*g/ggen.c`ファイル、例: `6g/ggen.c`はamd64、`8g/ggen.c`はarm)内に存在する関数で、Go関数のスタックフレームを設定するためのアセンブリコードを生成します。これには、ローカル変数のためのスペースの確保、レジスタの保存/復元、そして重要な「スタックフレームのゼロ初期化」が含まれます。

4.  **スタックフレームとゼロ初期化**:
    関数が呼び出されると、その関数が使用するローカル変数、引数、リターンアドレスなどを格納するためのメモリ領域がスタック上に確保されます。これを「スタックフレーム」と呼びます。Goでは、このスタックフレーム内の新しいメモリ領域(特にポインタを含む可能性のある領域)は、セキュリティ上の理由から自動的にゼロ値で初期化されます。これにより、以前の関数の実行によって残された機密情報や無効なポインタが、新しい変数に誤って読み込まれることを防ぎます。

5.  **`lo` と `hi` 変数**:
    `defframe`関数内で、スタックフレームのゼロ初期化が必要な範囲を管理するために使用される変数です。
    *   `lo` (low offset): ゼロ初期化が必要なメモリ範囲の開始オフセット(スタックフレームのベースからの相対位置)。
    *   `hi` (high offset): ゼロ初期化が必要なメモリ範囲の終了オフセット。
    コンパイラは、これらの変数を使って、複数のゼロ初期化要求を一つの連続した範囲にマージしようとします。

6.  **`widthreg` / `widthptr`**:
    *   `widthreg`: レジスタの幅(バイト単位)。例えば、64ビットアーキテクチャでは8バイト。
    *   `widthptr`: ポインタの幅(バイト単位)。これも通常はアーキテクチャのワードサイズに依存し、64ビットアーキテクチャでは8バイト。
    これらの定数は、メモリのアライメントやオフセット計算に使用されます。

## 技術的詳細

このコミットの核心は、`defframe`関数内のゼロ初期化範囲のマージロジックの修正です。`defframe`は、関数のスタックフレームを構築する際に、ゼロ初期化が必要な変数を特定し、それらのメモリ領域をゼロにするための命令を生成します。

ゼロ初期化の範囲は、`lo`と`hi`という変数によって管理されます。コンパイラは、スタック上の変数を処理する際に、その変数がゼロ初期化を必要とする場合、既存のゼロ初期化範囲(`lo`から`hi`まで)とマージできるかどうかを判断します。マージできると判断された場合、`lo`の値を更新して、より広い範囲をカバーするようにします。

元のコードでは、マージの条件が以下のようになっていました(`src/cmd/6g/ggen.c`の場合):
```c
if(n->xoffset + n->type->width >= lo - 2*widthptr) {
    // merge with range we already have
    lo = n->xoffset;
    continue;
}

そして、src/cmd/8g/ggen.cの場合:

if(n->xoffset + n->type->width == lo - 2*widthptr) {
    // merge with range we already have
    lo = n->xoffset;
    continue;
}

この条件は、「現在の変数nのメモリ領域が、既存のゼロ初期化範囲loの近くにあるか、またはそれに隣接しているか」をチェックしています。lo - 2*widthptrのようなオフセットは、アライメントやパディングを考慮したものです。

問題は、lohiがまだ有効なゼロ初期化範囲を示していない(例えば、初期状態や、前のゼロ初期化範囲が既に処理されてリセットされた後など)にもかかわらず、この条件が真になってしまう可能性があったことです。具体的には、lohiが同じ値(例えば、スタックフレームの初期オフセット)に設定されている場合、つまりゼロ初期化範囲が実質的に「空」である場合でも、上記の条件が満たされてしまい、lon->xoffsetに更新されてしまうことがありました。これにより、本来マージすべき既存の範囲がないにもかかわらず、マージ処理が実行され、結果として必要以上に広い範囲がゼロ初期化されてしまうというバグがありました。

このコミットでは、この問題を解決するために、マージ条件にlo != hiというチェックを追加しています。

コアとなるコードの変更箇所

src/cmd/6g/ggen.c

--- a/src/cmd/6g/ggen.c
+++ b/src/cmd/6g/ggen.c
@@ -45,7 +45,7 @@ defframe(Prog *ptxt)
 		if(n->type->width % widthreg != 0 || n->xoffset % widthreg != 0 || n->type->width == 0)
 			fatal("var %lN has size %d offset %d", n, (int)n->type->width, (int)n->xoffset);
 
-		if(n->xoffset + n->type->width >= lo - 2*widthptr) {
+		if(lo != hi && n->xoffset + n->type->width >= lo - 2*widthptr) {
 			// merge with range we already have
 			lo = n->xoffset;
 			continue;

src/cmd/8g/ggen.c

--- a/src/cmd/8g/ggen.c
+++ b/src/cmd/8g/ggen.c
@@ -42,7 +42,7 @@ defframe(Prog *ptxt)
 			fatal("needzero class %d", n->class);
 		if(n->type->width % widthptr != 0 || n->xoffset % widthptr != 0 || n->type->width == 0)
 			fatal("var %lN has size %d offset %d", n, (int)n->type->width, (int)n->xoffset);
-		if(n->xoffset + n->type->width == lo - 2*widthptr) {
+		if(lo != hi && n->xoffset + n->type->width == lo - 2*widthptr) {
 			// merge with range we already have
 			lo = n->xoffset;
 			continue;

コアとなるコードの解説

変更は両方のファイルで非常に似ており、既存のマージ条件の前に lo != hi && という条件が追加されています。

  • lo != hi: この新しい条件は、ゼロ初期化の範囲loからhiが実際に「非空」である場合にのみ、マージ処理を続行することを保証します。
    • もしlo == hiであれば、それは現在のゼロ初期化範囲がまだ設定されていないか、または既に処理されてリセットされた状態であることを意味します。このような場合、マージすべき既存の範囲は存在しないため、マージ処理はスキップされます。
    • これにより、コンパイラは、ゼロ初期化範囲が実際に存在し、かつ現在の変数とマージする意味がある場合にのみ、loの値を更新するようになります。

このシンプルな変更により、コンパイラが不必要に広いメモリ領域をゼロ初期化してしまうというバグが修正され、コード生成の効率が向上します。特に、スタックフレームのセットアップにおいて、厳密に必要とされるメモリ領域のみがゼロ初期化されるようになり、コンパイラが生成するコードの品質とパフォーマンスが改善されます。

関連リンク

参考にした情報源リンク

  • Go言語の公式ドキュメント
  • Goコンパイラのソースコード (特に src/cmd/gc ディレクトリ)
  • Go言語のスタックフレームとメモリ管理に関する一般的な知識
  • Goコンパイラの内部構造に関するコミュニティの議論やブログ記事 (具体的なURLは割愛しますが、一般的な知識として参照しました)
  • Go言語のコミット履歴とコードレビューシステム (Gerrit)