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

このコミットは、Go言語のテストスイートに test/stack.go という新しいテストファイルを追加するものです。このテストの主な目的は、Goランタイムにおけるスタック分割（stack splitting）のバグを特定し、再現することです。特に、異なるスタック深度で go ステートメント（ゴルーチンの起動）と defer ステートメント（遅延実行関数の登録）を組み合わせることで、スタック管理の潜在的な問題をあぶり出すように設計されています。

コミット

このコミットは、Goランタイムのスタック管理メカニズム、特にスタックの動的な拡張（スタック分割）が正しく機能していることを検証するためのテストを追加します。Goの初期開発段階において、ゴルーチンのスタックは必要に応じて自動的に拡張される設計でしたが、この複雑なメカニズムにはバグが潜む可能性がありました。このテストは、その堅牢性を確認するために作成されました。

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

https://github.com/golang/go/commit/6ee6d6ec55efac70555e49728902ff0c10630b8f

元コミット内容

add stack test

R=r
DELTA=48  (48 added, 0 deleted, 0 changed)
OCL=23715
CL=23732

変更の背景

このコミットが行われた2009年1月は、Go言語がまだ一般に公開される前の非常に初期の開発段階でした。当時のGoランタイムは、軽量な並行処理を実現するためにゴルーチン（goroutine）という概念を導入しており、そのゴルーチンは非常に小さなスタック（数KB程度）で開始され、必要に応じて自動的にスタックを拡張する「スタック分割（stack splitting）」というメカニズムを持っていました。

スタック分割は、数百万ものゴルーチンを効率的に実行するために不可欠な機能でしたが、その実装は非常に複雑であり、潜在的なバグの温床となる可能性がありました。特に、関数呼び出しの深さ、再帰、go ステートメントによる新しいゴルーチンの起動、そして defer ステートメントによる遅延実行関数の登録といった要素が絡み合うと、スタックの拡張や縮小のロジックに問題が生じやすくなります。

この add stack test コミットは、まさにそのような複雑なシナリオをシミュレートし、スタック分割メカニズムが意図通りに機能しているか、特にスタックのオーバーフローや不正なメモリアクセスといったバグが発生しないかを検証するために追加されました。Go言語の安定性と信頼性を確保するための、初期段階における重要な品質保証活動の一環と言えます。

前提知識の解説

Go言語のゴルーチン (Goroutines)

Go言語のゴルーチンは、軽量な並行処理の単位です。OSのスレッドよりもはるかに軽量で、数百万個を同時に実行することも可能です。ゴルーチンはGoランタイムによって管理され、OSのスレッドに多重化されて実行されます。

Go言語のチャネル (Channels)

チャネルは、ゴルーチン間で値を安全に送受信するための通信メカニズムです。チャネルを通じてデータをやり取りすることで、共有メモリによる競合状態を避けることができます。

Go言語の `defer` ステートメント

defer ステートメントは、その関数がリターンする直前に実行される関数呼び出しをスケジュールします。これは、リソースの解放（ファイルのクローズ、ロックの解除など）や、エラーハンドリングのクリーンアップ処理によく使用されます。defer された関数はLIFO（後入れ先出し）の順序で実行されます。

Go言語のスタック分割 (Stack Splitting)

Goのゴルーチンは、非常に小さなスタック（初期は数KB）で開始されます。関数呼び出しが深くなり、スタックが不足しそうになると、Goランタイムは自動的に現在のスタックをより大きな新しいスタックにコピーし、古いスタックを解放します。このプロセスを「スタック分割」と呼びます。これにより、ゴルーチンは必要なだけスタックを動的に拡張でき、メモリを効率的に利用できます。しかし、この動的なスタック管理は複雑であり、特に並行処理と組み合わせると、デッドロック、スタックオーバーフロー、または不正なメモリ参照などのバグを引き起こす可能性があります。

`panicln`

Go言語の組み込み関数で、引数を結合してエラーメッセージとしてパニックを発生させます。テストにおいて、予期せぬ状態が発生した場合にプログラムの実行を停止させるために使用されます。

技術的詳細

test/stack.go は、Goランタイムのスタック管理、特にスタック分割の堅牢性を検証するために設計されたテストです。このテストは、再帰呼び出し、ゴルーチンの起動、チャネル通信、そして defer ステートメントを組み合わせて、スタックの動的な拡張と縮小が正しく行われることを確認します。

テストの主要なコンポーネントは以下の通りです。

T 型: [20]int の配列型で、スタック上で一定のメモリを消費する構造体として使用されます。これにより、関数呼び出しごとにスタック使用量をシミュレートします。
g(c chan int, t T) 関数:
- 新しいゴルーチンで実行される関数です。
- 引数 t (型 T) を受け取り、その要素の合計を計算します。
- 計算結果をチャネル c に送信します。
- この関数は、ゴルーチンが起動されたときにスタックが正しく割り当てられ、使用できることを確認します。
d(t T) 関数:
- defer ステートメントによって遅延実行される関数です。
- 引数 t (型 T) を受け取り、その要素の合計を計算します。
- 合計が len(t) (つまり20) と等しくない場合、panicln を呼び出してテストを失敗させます。これは、t のすべての要素が1に初期化されていることを前提としています。
- この関数は、defer された関数が正しいスタックコンテキストで、かつ正しい引数で実行されることを確認します。
recur(n int) 関数:
- 再帰的に呼び出される関数で、スタック深度を深くするために使用されます。
- go g(c, t): 各再帰呼び出しで新しいゴルーチン g を起動します。これにより、多数のゴルーチンが同時に存在し、それぞれがスタックを必要とする状況を作り出します。
- s := <-c: 起動したゴルーチン g からの結果をチャネル c 経由で受け取ります。これにより、ゴルーチン間の同期と通信がテストされます。
- if s != len(t) { panicln("bad go", s) }: g から返された値が期待通りでない場合、テストを失敗させます。
- if n > 0 { recur(n-1) }: n が0より大きい場合、自身を再帰的に呼び出します。これにより、スタック深度が深くなります。
- defer d(t): 各再帰呼び出しの最後に d 関数を defer します。これにより、多数の defer された関数がスタック上に積まれ、関数がリターンする際にそれらが正しい順序で、かつ正しいコンテキストで実行されることをテストします。
main() 関数:
- t (型 T) のすべての要素を1に初期化します。
- recur(10000): recur 関数を10000回再帰的に呼び出します。これは非常に深いスタック深度と、10000個のゴルーチン起動、10000個の defer された関数を伴うため、スタック分割メカニズムに大きな負荷をかけます。

このテストは、Goランタイムが以下のシナリオでスタックを正しく管理できることを検証します。

深い再帰呼び出しにおけるスタックの拡張。
多数のゴルーチンが同時に起動され、それぞれがスタックを必要とする状況。
defer された関数が、その関数が定義された時点のスタックコンテキストと引数で正しく実行されること。
これらの複合的な操作が、スタックオーバーフローやメモリ破損を引き起こさないこと。

特に、panicln を使用して期待される結果が得られない場合にテストを失敗させることで、スタック管理の不具合を早期に検出する役割を果たします。

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

このコミットでは、test/stack.go という新しいファイルが追加されています。

--- /dev/null
+++ b/test/stack.go
@@ -0,0 +1,52 @@
+// $G $D/$F.go && $L $F.$A && ./$A.out
+//
+// Copyright 2009 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+//
+// Try to tickle stack splitting bugs by doing
+// go and defer at different stack depths.
+//
+package main
+
+type T [20] int;
+
+func g(c chan int, t T) {
+	s := 0;
+	for i := 0; i < len(t); i++ {
+		s += t[i];
+	}
+	c <- s;
+}
+
+func d(t T) {
+	s := 0;
+	for i := 0; i < len(t); i++ {
+		s += t[i];
+	}
+	if s != len(t) {
+		panicln("bad defer", s);
+	}
+}
+
+var c = make(chan int);
+var t T;
+
+func recur(n int) {
+	go g(c, t);
+	s := <-c;
+	if s != len(t) {
+		panicln("bad go", s);
+	}
+	if n > 0 {
+		recur(n-1);
+	}
+	defer d(t);
+}
+
+func main() {
+	for i := 0; i < len(t); i++ {
+		t[i] = 1;
+	}
+	recur(10000);
+}

コアとなるコードの解説

ファイルヘッダとコメント

// $G $D/$F.go && $L $F.$A && ./$A.out
//
// Copyright 2009 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
//
// Try to tickle stack splitting bugs by doing
// go and defer at different stack depths.

この部分は、テストの実行方法（Goコンパイラ $G、リンカ $L を使用してコンパイルし、実行可能ファイル $A.out を実行する）と、著作権情報、そしてこのテストの目的が簡潔に記述されています。「異なるスタック深度で go と defer を行うことで、スタック分割のバグをあぶり出すことを試みる」と明記されており、テストの意図が明確です。

`package main`

package main

このファイルが実行可能なプログラムであることを示します。

`type T [20] int;`

type T [20] int;

T という新しい型を定義しています。これは20個の整数を格納できる配列です。この型は、関数に渡される際にスタック上で一定のメモリを消費するオブジェクトとして機能し、スタック使用量をシミュレートするために使われます。

`func g(c chan int, t T)`

func g(c chan int, t T) {
	s := 0;
	for i := 0; i < len(t); i++ {
		s += t[i];
	}
	c <- s;
}

この関数は、新しいゴルーチンで実行されることを想定しています。

c chan int: 整数を送信するためのチャネル。
t T: 型 T の配列。関数は t の全要素の合計を計算し、その結果をチャネル c に送信します。これは、ゴルーチンが正しく起動され、引数を渡し、計算を行い、結果を返すことができるかをテストします。

`func d(t T)`

func d(t T) {
	s := 0;
	for i := 0; i < len(t); i++ {
		s += t[i];
	}
	if s != len(t) {
		panicln("bad defer", s);
	}
}

この関数は defer ステートメントによって遅延実行されることを想定しています。

t T: 型 T の配列。関数は t の全要素の合計を計算します。もし合計が len(t) (つまり20) と等しくない場合、panicln を呼び出してエラーメッセージ "bad defer" と共にパニックを発生させます。これは、defer された関数が正しい引数（この場合は t の値）を受け取り、正しく実行されることを検証します。t の要素は main 関数で全て1に初期化されるため、合計は常に len(t) になるはずです。

グローバル変数 `c` と `t`

var c = make(chan int);
var t T;

c: 整数型チャネルのグローバル変数。ゴルーチン g と recur 関数間の通信に使用されます。
t: 型 T のグローバル変数。main 関数で初期化され、g と d 関数に引数として渡されます。

`func recur(n int)`

func recur(n int) {
	go g(c, t);
	s := <-c;
	if s != len(t) {
		panicln("bad go", s);
	}
	if n > 0 {
		recur(n-1);
	}
	defer d(t);
}

この関数はテストの核心部分です。

go g(c, t);: 新しいゴルーチンとして g 関数を起動します。これにより、並行処理の負荷をかけます。
s := <-c;: 起動した g ゴルーチンからの結果をチャネル c から受け取ります。
if s != len(t) { panicln("bad go", s); }: g からの戻り値が期待通りでない場合（t の要素の合計が len(t) と異なる場合）、"bad go" エラーでパニックします。これは、ゴルーチンが正しく実行され、チャネル通信が機能していることを確認します。
if n > 0 { recur(n-1); }: n が0より大きい場合、recur 関数自身を再帰的に呼び出します。これにより、関数呼び出しのスタック深度が深くなり、スタック分割がトリガーされる可能性が高まります。
defer d(t);: recur 関数がリターンする直前に d 関数が実行されるようにスケジュールします。再帰呼び出しのたびに defer が積まれるため、非常に多くの d 関数がスタック上に待機することになります。これにより、defer のメカニズムとスタック管理の相互作用がテストされます。

`func main()`

func main() {
	for i := 0; i < len(t); i++ {
		t[i] = 1;
	}
	recur(10000);
}

プログラムのエントリポイントです。

for i := 0; i < len(t); i++ { t[i] = 1; }: グローバル変数 t のすべての要素を1に初期化します。これにより、g 関数と d 関数での合計値の検証が容易になります（合計が常に len(t) になる）。
recur(10000);: recur 関数を10000回再帰的に呼び出します。この深い再帰と、各呼び出しでのゴルーチン起動および defer の登録が、Goランタイムのスタック分割メカニズムに極めて高い負荷をかけ、潜在的なバグをあぶり出すことを目的としています。

このコード全体は、Goランタイムのスタック管理、特にスタック分割、ゴルーチン、チャネル、そして defer の組み合わせが、極端な条件下でも堅牢に機能することを検証するための包括的なストレステストとして機能します。

参考にした情報源リンク

Go言語のスタック管理に関する議論（初期の設計ドキュメントやメーリングリストのアーカイブなど、当時の情報源を特定することは困難ですが、Goのスタック分割は初期から重要な設計要素でした。）
Go言語のソースコード（特に runtime パッケージ）
Go言語のテストスイートの構造と慣習