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

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

src/cmd/gc/subr.c は、Goコンパイラ (cmd/gc) のソースコードの一部であり、主にコンパイラのバックエンドにおけるサブルーチンやユーティリティ関数を実装しています。これには、コード生成、型システムとの連携、そして今回変更されたような、コンパイラが内部的に生成する特殊な関数の処理などが含まれます。このコミットは、特にインターフェース変換のために自動生成されるラッパー関数のデバッグ情報生成メカニズムに焦点を当てた変更です。

コミット

  • コミットハッシュ: 8195ce2b4f430023522f28e6666850bbfb85c31b

  • 作者: Rob Pike r@golang.org

  • 日付: Mon Jun 2 16:01:53 2014 -0700

  • コミットメッセージ:

    cmd/gc: ラッパー関数のために大量のlinehistを生成しないようにする
これはワークアラウンドである - コードはこれよりも優れているべきだが -
この修正は、インターフェース変換を可能にするラッパー関数のために
大量のlinehistエントリが生成されるのを回避する。
これらの関数は多数存在し、コンパイルの最後にすべて生成され、
そしてすべてが単一のlinehistエントリを共有できる。
liblinkにおける悪いN^2の挙動を回避する。
Issue 8135のテストケースでは、64秒から2.5秒に短縮される（まだ悪いが許容範囲内）。

Fixes #8135.

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

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

https://github.com/golang/go/commit/8195ce2b4f430023522f28e6666850bbfb85c31b

元コミット内容

Goコンパイラ (cmd/gc) が、インターフェース変換のために自動生成するラッパー関数について、過剰な数の行履歴 (linehist) エントリを生成しないようにする修正です。これは一時的な回避策であり、本来はより洗練された解決策が望ましいとされています。この修正により、多数のラッパー関数が単一の行履歴エントリを共有できるようになり、リンカ (liblink) における非効率なO(N^2)のパフォーマンス挙動が回避されます。結果として、Issue 8135で報告された特定のテストケースのコンパイル時間が64秒から2.5秒へと劇的に短縮されました。

変更の背景

Go言語のコンパイラは、インターフェースの動的な性質をサポートするために、特定の状況下で「ラッパー関数」と呼ばれる小さなコードスニペットを自動的に生成します。例えば、具体的な型がインターフェース型に変換される際や、インターフェース値を通じてメソッドが呼び出される際に、これらのラッパー関数が介在して適切なメソッドディスパッチを行います。

問題は、これらのラッパー関数が多数生成される場合に発生しました。Goコンパイラは、生成された各コードブロックに対して、デバッグ情報の一部として「行履歴 (linehist)」エントリを記録します。この行履歴は、ソースコードの行番号とコンパイルされた機械語コードのアドレスとのマッピングを提供し、デバッガがソースレベルでのステップ実行やスタックトレースの表示を行う際に不可欠な情報です。

しかし、多数のラッパー関数がそれぞれ独自のlinehistエントリを持つことで、コンパイルの最終段階でリンカ (liblink) がこれらのエントリを処理する際に、処理時間がエントリ数の二乗に比例して増加する（O(N^2)の挙動）という深刻なパフォーマンスボトルネックが発生していました。これは、特に大規模なGoプログラムや、インターフェースを多用するコードベースにおいて、コンパイル時間が非常に長くなる原因となっていました。

このコミットは、このパフォーマンス問題を緩和するための緊急的な「ワークアラウンド」として導入されました。目標は、リンカが処理するlinehistエントリの数を大幅に削減し、コンパイル時間を許容できるレベルにまで短縮することでした。

前提知識の解説

このコミットの理解を深めるために、以下のGo言語およびコンパイラに関する基本的な概念を理解しておく必要があります。

  • Goコンパイラ (cmd/gc): Go言語の公式コンパイラは、cmd/gcとして知られています。これは、Goのソースコードを解析し、中間表現に変換し、最終的にターゲットアーキテクチャの機械語コードを生成する役割を担います。コンパイルプロセスは複数のステージに分かれており、字句解析、構文解析、型チェック、最適化、コード生成などが含まれます。src/cmd/gc/subr.cは、このコンパイラのバックエンド部分、特にコード生成やユーティリティ機能に関連するサブルーチンを実装しているファイルです。

  • ラッパー関数 (Wrapper Functions): Go言語のインターフェースは、ポリモーフィズムを実現するための強力な機能です。インターフェースはメソッドのセットを定義し、任意の型がそのメソッドセットを実装していれば、そのインターフェース型として扱われます。 コンパイラは、具体的な型からインターフェース型への変換（例: var i io.Reader = myFile{}）や、インターフェース値を通じてメソッドを呼び出す（例: i.Read(...)）際に、内部的に小さな「ラッパー関数」を生成することがあります。これらのラッパー関数は、実行時に適切な具体的な型のメソッドを呼び出すための橋渡し役を果たします。これらはGoプログラマが直接記述するものではなく、コンパイラによって透過的に生成されるコードです。

  • linehist (Line History): linehistは「行履歴」の略で、コンパイルされたバイナリに含まれるデバッグ情報の一種です。この情報は、ソースコードの特定の行が、コンパイルされた機械語コードのどのメモリアドレスに対応するかをマッピングします。デバッガ（例: delve）がプログラムの実行をソースコードレベルで追跡したり、エラー発生時に正確なスタックトレース（どのファイル、どの行でエラーが発生したか）を表示したりするために不可欠です。 Goコンパイラ内部では、linehist関数が呼び出されることで、この行履歴エントリが生成され、最終的なバイナリに埋め込まれます。通常、ソースコードの各行や重要なコードブロックの開始点に対して、対応するlinehistエントリが生成されます。

  • liblink (Go Linker): liblinkは、Go言語のリンカの内部名称です。コンパイラによって生成された複数のオブジェクトファイル（.oファイルなど、機械語コードが含まれる）を結合し、必要なライブラリとリンクして、最終的な実行可能バイナリを生成する役割を担います。リンカのタスクには、シンボルの解決（関数や変数の定義と参照を紐付ける）、静的ライブラリや共有ライブラリの組み込み、そしてデバッグ情報の最終的な整理とバイナリへの埋め込みが含まれます。 このコミットで言及されている「N^2の挙動」とは、リンカがlinehistエントリを処理する際に、エントリの数が増えるにつれて処理時間が非線形に、具体的にはエントリ数の二乗に比例して増加するという、非常に非効率なアルゴリズムを使用していたことを示しています。これは、エントリ数が少し増えるだけでも、処理時間が爆発的に増加する可能性があることを意味します。

技術的詳細

このコミットの技術的な核心は、Goコンパイラが自動生成するラッパー関数に対するlinehistエントリの生成方法を変更し、リンカのパフォーマンスボトルネックを回避することにあります。

変更前は、genwrapper関数（ラッパー関数を生成するGoコンパイラの内部関数）が呼び出されるたびに、無条件にlinehist("<autogenerated>", 0, 0);が実行されていました。これは、生成されるラッパー関数の数だけ、<autogenerated>という仮想的なソースファイルと行番号に対応する新しいlinehistエントリがリンカに渡されることを意味します。インターフェースを多用するプログラムでは、このラッパー関数が数千、数万と生成されることがあり、その結果、リンカが処理しなければならないlinehistエントリの数が膨大になっていました。

リンカ (liblink) は、これらの大量のlinehistエントリを処理する際に、エントリの数に対してO(N^2)の計算量を持つ非効率なアルゴリズムを使用していたため、エントリ数が増加するにつれてコンパイル時間が許容できないほど長くなっていました。

このコミットでは、この問題を解決するために、genwrapper関数内にstatic int linehistdone = 0;という静的変数を導入しました。

  • static変数の利用: staticキーワードは、変数がその関数が呼び出されるたびに初期化されるのではなく、プログラムの実行期間を通じてその値を保持することを意味します。linehistdoneは、genwrapper関数が最初に呼び出されたときに0に初期化されます。

  • 条件付きlinehist生成:

    if (linehistdone == 0) {
    // All the wrappers can share the same linehist entry.
    linehist("<autogenerated>", 0, 0);
    linehistdone = 1;
}

    このコードブロックは、linehistdoneが0の場合にのみ実行されます。つまり、genwrapper関数がプログラムのコンパイル中に最初に呼び出されたときに一度だけ、linehist("<autogenerated>", 0, 0);が実行されます。 linehistが一度呼び出された後、linehistdoneは1に設定されます。これにより、以降のgenwrapperの呼び出しではif (linehistdone == 0)の条件が偽となり、linehistの呼び出しはスキップされます。

この変更の結果、Goコンパイラが生成するすべての自動生成ラッパー関数は、単一の<autogenerated>という仮想的なソース位置に対応するlinehistエントリを共有するようになります。これにより、リンカが処理しなければならないlinehistエントリの総数が劇的に削減され、リンカのO(N^2)のパフォーマンス問題が実質的に回避されました。

コミットメッセージにあるように、これは「ワークアラウンド」であり、根本的な解決策ではありません。理想的には、リンカが多数のlinehistエントリを効率的に処理できるようなアルゴリズムに改善されるべきか、あるいはコンパイラがよりスマートにlinehistエントリを生成するべきです。しかし、このシンプルな回避策によって、Issue 8135で報告されたような極端なコンパイル時間の問題が解決され、実用的なパフォーマンス改善が達成されました。

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

変更は、Goコンパイラのソースコードファイル src/cmd/gc/subr.c の genwrapper 関数内で行われました。

--- a/src/cmd/gc/subr.c
+++ b/src/cmd/gc/subr.c
@@ -2493,6 +2493,7 @@ genwrapper(Type *rcvr, Type *method, Sym *newnam, int iface)
 	Type *tpad, *methodrcvr;
 	int isddd;
 	Val v;
+	static int linehistdone = 0; // <-- この行が追加されました
 
 	if(0 && debug['r'])
 		print("genwrapper rcvrtype=%T method=%T newnam=%S\n",
@@ -2500,7 +2501,11 @@ genwrapper(Type *rcvr, Type *method, Sym *newnam, int iface)
 
 	lexlineno++;
 	lineno = lexlineno;
-	linehist("<autogenerated>", 0, 0); // <-- この行が変更されました
+	if (linehistdone == 0) { // <-- このブロックが追加されました
+		// All the wrappers can share the same linehist entry.
+		linehist("<autogenerated>", 0, 0);
+		linehistdone = 1;
+	}
 
 	dclcontext = PEXTERN;
 	markdcl();

コアとなるコードの解説

genwrapper関数は、Goコンパイラがインターフェースのメソッド呼び出しや型変換を処理するために必要な、内部的なラッパー関数を生成する際に呼び出されます。

変更前は、この関数が呼び出されるたびに、以下の行が実行されていました。

linehist("<autogenerated>", 0, 0);

これは、genwrapperが実行されるたびに、<autogenerated>という仮想的なソースファイル名と、行番号0、列番号0に対応する新しい行履歴エントリが生成されることを意味します。多数のラッパー関数が生成されると、この行が何度も実行され、結果としてリンカが処理しなければならない行履歴エントリが爆発的に増加していました。

このコミットでは、この問題を解決するために、genwrapper関数の冒頭に以下の静的変数が追加されました。

static int linehistdone = 0;

staticキーワードにより、linehistdone変数はgenwrapper関数が最初に呼び出されたときに一度だけ0に初期化され、その後はプログラムの実行期間を通じてその値を保持します。

そして、元のlinehistの呼び出しは、以下の条件ブロックで囲まれました。

if (linehistdone == 0) {
    // All the wrappers can share the same linehist entry.
    linehist("<autogenerated>", 0, 0);
    linehistdone = 1;
}

この変更により、genwrapper関数が最初に呼び出されたとき（つまりlinehistdoneが0のとき）にのみ、linehist("<autogenerated>", 0, 0);が実行されます。この一度の呼び出しの後、linehistdoneは1に設定されます。

その結果、genwrapperが二回目以降に呼び出された際には、if (linehistdone == 0)の条件が偽となるため、linehistの呼び出しはスキップされます。これにより、すべての自動生成ラッパー関数が、コンパイルプロセス中に一度だけ生成された単一の<autogenerated>行履歴エントリを共有するようになります。

このシンプルな変更によって、リンカが処理する行履歴エントリの総数が大幅に削減され、リンカのO(N^2)のパフォーマンス問題が実質的に解消され、コンパイル時間が劇的に改善されました。

関連リンク

参考にした情報源リンク

  • Go言語のコンパイラ設計に関する一般的な情報源 (例: Goの公式ドキュメント、Goコンパイラのソースコードコメント)
  • Go言語のインターフェースの内部実装に関する情報 (例: Goのブログ記事、技術解説記事)
  • デバッグ情報（DWARFなど）とリンカの動作に関する一般的な知識