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

このコミットは、Goランタイムにおけるreflect.Callの実装を、スタック分割（stack splitting）を使用しない形に再設計するものです。これにより、特に大きな引数を持つ関数をreflect.Call経由で呼び出す際のパフォーマンスと安定性の問題が解決されます。

コミット

commit 9cd570680bd1d6ea23e4f5da1fe3a50c6927d6d5
Author: Keith Randall <khr@golang.org>
Date:   Fri Aug 2 13:03:14 2013 -0700

    runtime: reimplement reflect.call to not use stack splitting.
    
    R=golang-dev, r, khr, rsc
    CC=golang-dev
    https://golang.org/cl/12053043

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

https://github.com/golang/go/commit/9cd570680bd1d6ea23e4f5da1fe3a50c6927d6d5

元コミット内容

reflect.callをスタック分割を使用しないように再実装。

変更の背景

Go言語のreflect.Callは、リフレクションを通じて任意の関数を呼び出すための強力な機能です。しかし、この機能がGoランタイムのスタック管理メカニズム、特に「スタック分割（stack splitting）」とどのように連携するかが問題となっていました。

従来のreflect.Callの実装では、呼び出される関数の引数サイズが事前に不明なため、スタック分割のメカニズムに依存していました。スタック分割は、Goのgoroutineが小さなスタックで開始し、必要に応じて自動的にスタックを拡張する機能です。これは、数百万ものgoroutineを効率的に実行するために不可欠な機能ですが、reflect.Callのような動的な呼び出しにおいては、引数サイズが非常に大きい場合に非効率性や潜在的な問題を引き起こす可能性がありました。

具体的には、reflect.Callが非常に大きな引数を伴う関数を呼び出す際、スタック分割のプロセスが何度も発生し、オーバーヘッドが増大したり、最悪の場合、スタックの割り当てに失敗してパニックを引き起こす可能性がありました。このコミットは、この問題を解決し、reflect.Callがより堅牢で効率的に動作するようにするためのものです。src/pkg/reflect/all_test.goに追加されたTestBigArgsは、この問題が実際に存在し、大きな引数でreflect.Callがパニックを起こすことを示しています。

前提知識の解説

Goのスタック管理とスタック分割 (Stack Splitting)

Goランタイムは、各goroutineに比較的小さなスタック（通常は数KB）を割り当てて開始します。これは、多数のgoroutineを同時に実行する際のメモリ効率を高めるためです。関数が呼び出され、そのスタックフレームが現在のスタックの残りの容量を超えそうになると、Goランタイムは自動的に新しい、より大きなスタックセグメントを割り当て、古いスタックの内容を新しいスタックにコピーします。このプロセスを「スタック分割」と呼びます。

スタック分割は透過的に行われ、開発者が意識することなく動的にスタックサイズを調整できるため、非常に便利です。しかし、このプロセスにはオーバーヘッドが伴います。特に、非常に大きなスタックフレーム（例えば、巨大な配列を値渡しで引数として取る場合など）が必要な関数が頻繁に呼び出されると、スタック分割が繰り返し発生し、パフォーマンスに影響を与える可能性があります。

reflect.Call

reflect.Callは、Goのリフレクションパッケージの一部であり、実行時に型情報に基づいて関数を呼び出す機能を提供します。これは、例えば、コマンドラインツールやRPCフレームワーク、テストフレームワークなどで、関数の名前や引数の型がコンパイル時には不明な場合に非常に有用です。

reflect.Callは、呼び出す関数の引数を[]reflect.Valueとして受け取り、戻り値を[]reflect.Valueとして返します。この動的な性質のため、ランタイムは呼び出し時に引数のサイズを正確に把握し、それに応じてスタックを準備する必要があります。

アセンブリ言語とGoランタイム

Goランタイムの多くの部分は、パフォーマンスと低レベルな制御のためにアセンブリ言語で書かれています。特に、スタック管理、スケジューリング、ガベージコレクションなどのコア機能は、特定のCPUアーキテクチャ（x86, amd64, ARMなど）に最適化されたアセンブリコードで実装されています。reflect.Callのようなリフレクション機能も、最終的にはこれらの低レベルなアセンブリルーチンを介して実際の関数呼び出しを行います。

技術的詳細

このコミットの核心は、reflect.Callがスタック分割に依存するのをやめ、代わりに固定サイズのスタックフレームを持つ複数のアセンブリ関数を動的にディスパッチするメカニズムを導入した点にあります。

従来のreflect.Callは、runtime.morestack（スタック分割のトリガーとなる関数）に似たアプローチで、引数を新しいスタックにコピーし、関数を呼び出すことでスタックの拡張を期待していました。しかし、引数サイズが非常に大きい場合、この「スタック分割に任せる」アプローチでは、スタックのコピーが頻繁に発生したり、スタックガード（スタックオーバーフローを防ぐための境界）のチェックが複雑になったりする問題がありました。

新しいアプローチでは、reflect.Callは引数のサイズに基づいて、あらかじめ定義された複数の固定サイズのアセンブリ関数（例: runtime.call16, runtime.call32, ..., runtime.call1073741824）のいずれかにディスパッチします。これらの関数は、それぞれ16バイト、32バイト、...、1GBといった特定の最大引数サイズに対応するスタックフレームを確保します。

1. reflect.callの変更: reflect.callは、引数のサイズ（argsize）を受け取り、そのサイズに最も適したruntime.callN関数（Nは引数サイズ）を決定します。
2. DISPATCHマクロ: 各アーキテクチャのアセンブリファイル（asm_386.s, asm_amd64.s, asm_arm.s）には、DISPATCHマクロが導入されています。これは、argsizeとMAXSIZEを比較し、argsizeがMAXSIZE以下であれば対応するruntime.callN関数にジャンプします。これにより、引数サイズに応じた適切なスタックフレームを持つ関数が選択されます。
3. CALLFNマクロ: CALLFNマクロは、実際に引数をスタックにコピーし、ターゲット関数を呼び出し、戻り値をコピーする一連の処理をカプセル化します。これにより、多数のruntime.callN関数を簡潔に定義できます。
   • argptrからargsizeバイトの引数を現在のスタックポインタ（SP）が指す位置にコピーします。
   • ターゲット関数（f）を呼び出します。
   • 戻り値をスタックからargptrにコピーし直します。
4. runtime.newstackcallへのリネーム: 以前reflect.callと呼ばれていた、スタック分割を模倣する汎用的なスタック成長コードは、runtime.newstackcallにリネームされました。これは、パニック処理など、reflect.Callとは異なる文脈でスタックを拡張する必要がある場合に使用されます。
5. エラーハンドリング: 引数サイズが1GBを超えるような極端なケースでは、runtime.badreflectcallが呼び出され、パニックが発生するようになります。これは、現実的な引数サイズの上限を設定し、不正な使用を防ぐためです。
6. リンカの変更: src/cmd/ld/lib.cでは、スタック調整値（spadj）の許容範囲が拡張されています。これは、新しいreflect.Callの実装が、より大きなスタックフレームを扱う可能性があるため、リンカがそれを正しく処理できるようにするための調整です。
7. テストの追加: src/pkg/reflect/all_test.goにTestBigArgsが追加され、大きな引数を持つ関数をreflect.Callで呼び出すとパニックが発生することを確認しています。これは、新しい実装が意図した通りに動作し、特定のケースでパニックを引き起こすことを検証するためのものです。

この変更により、reflect.Callはスタック分割のオーバーヘッドを回避し、引数サイズに応じた最適なスタックフレームを直接利用できるようになります。これにより、特に大きな引数を扱う際のリフレクション呼び出しのパフォーマンスと信頼性が向上します。

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

src/pkg/runtime/asm_386.s, src/pkg/runtime/asm_amd64.s, src/pkg/runtime/asm_arm.s

これらのファイルは、各アーキテクチャにおけるreflect.callの新しい実装を含んでいます。

• reflect.call関数が、引数サイズに基づいてruntime.callN関数群にディスパッチするロジックに変更されました。
• DISPATCHマクロとCALLFNマクロが導入され、多数の固定サイズフレーム関数を効率的に定義しています。
• 以前のreflect.callに相当するスタック成長コードはruntime.newstackcallにリネームされました。

例 (asm_amd64.s):

#define DISPATCH(NAME,MAXSIZE)		\
	CMPQ	CX, $MAXSIZE;		\
	JA	3(PC);			\
	MOVQ	$runtime·NAME(SB), AX;	\
	JMP	AX

TEXT reflect·call(SB), 7, $0-20
	MOVLQZX argsize+16(FP), CX
	DISPATCH(call16, 16)
	DISPATCH(call32, 32)
	// ... (中略) ...
	DISPATCH(call1073741824, 1073741824)
	MOVQ	$runtime·badreflectcall(SB), AX
	JMP	AX

#define CALLFN(NAME,MAXSIZE,FLAGS)		\
TEXT runtime·NAME(SB), FLAGS, $MAXSIZE-20;	\
	/* copy arguments to stack */		\
	MOVQ	argptr+8(FP), SI;		\
	MOVLQZX argsize+16(FP), CX;		\
	MOVQ	SP, DI;				\
	REP;MOVSB;				\
	/* call function */			\
	MOVQ	f+0(FP), DX;			\
	CALL	(DX);				\
	/* copy return values back */		\
	MOVQ	argptr+8(FP), DI;		\
	MOVLQZX	argsize+16(FP), CX;		\
	MOVQ	SP, SI;				\
	REP;MOVSB;				\
	RET

CALLFN(call16, 16, 7)
CALLFN(call32, 32, 7)
// ... (中略) ...
CALLFN(call1073741824, 1073741824, 0)

src/pkg/reflect/all_test.go

大きな引数を持つ関数をreflect.Callで呼び出すテストケースTestBigArgsが追加されました。このテストは、通常の関数呼び出しは問題ないが、reflect.Callではパニックが発生することを期待しています。

func bigArgFunc(v [(1<<30)+64]byte) {
}

func TestBigArgs(t *testing.T) {
	if !testing.Short() && ^uint(0)>>32 != 0 { // test on 64-bit only
		v := new([(1<<30)+64]byte)
		bigArgFunc(*v) // regular calls are ok
		shouldPanic(func() {ValueOf(bigArgFunc).Call([]Value{ValueOf(*v)})}) // ... just not reflect calls
	}
}

src/pkg/runtime/panic.c

パニック処理において、reflect.callへの参照がruntime.newstackcallに変更されました。

// old: reflect·call(d->fn, (byte*)d->args, d->siz);
// new: runtime·newstackcall(d->fn, (byte*)d->args, d->siz);

src/pkg/runtime/proc.c

引数サイズが大きすぎる場合にパニックを引き起こすruntime.badreflectcall関数が追加されました。

void
runtime·badreflectcall(void) // called from assembly
{
	runtime·panicstring("runtime: arg size to reflect.call more than 1GB");
}

src/pkg/runtime/runtime.h

runtime.newstackcallの宣言が追加されました。

void	runtime·newstackcall(FuncVal*, byte*, uint32);

src/pkg/runtime/stack.c

runtime.newstack関数内で、reflectcallというフラグがnewstackcallにリネームされ、runtime.newstackcallからの呼び出しを区別するために使用されます。

// old: bool reflectcall;
// new: bool newstackcall;

// old: reflectcall = framesize==1;
// new: newstackcall = framesize==1;

// old: if(reflectcall)
// new: if(newstackcall)

コアとなるコードの解説

このコミットの最も重要な変更は、reflect.Callの内部実装が、動的なスタック分割に依存するのではなく、引数サイズに応じた固定サイズのスタックフレームを持つ専用のアセンブリ関数群にディスパッチするようになった点です。

1. reflect.callのディスパッチロジック:

   • reflect.callは、呼び出される関数の引数サイズ（argsize）を取得します。
   • DISPATCHマクロの連鎖により、argsizeが収まる最小のMAXSIZEに対応するruntime.callN関数にジャンプします。例えば、argsizeが20バイトならruntime.call32が選ばれます。
   • これにより、ランタイムは事前に必要なスタックサイズを把握し、適切なスタックフレームを持つ関数を直接呼び出すことができます。

2. CALLFNマクロによる固定サイズフレーム関数の生成:

   • CALLFNマクロは、runtime.call16からruntime.call1073741824までの多数の関数を生成します。
   • これらの関数は、MAXSIZEで指定されたサイズのスタックフレームを確保します。
   • 引数（argptrが指すメモリ領域）を新しく確保されたスタックフレームにコピーします。
   • ターゲット関数（f）を呼び出します。
   • ターゲット関数からの戻り値を、元の引数領域（argptr）にコピーし直します。
   • このアプローチにより、スタック分割のオーバーヘッドなしに、効率的に引数を渡し、関数を呼び出すことが可能になります。

3. runtime.newstackcallの役割:

   • 以前のreflect.callが担っていた、スタックが不足した場合に新しいスタックを割り当てて関数を呼び出す汎用的なロジックは、runtime.newstackcallとして分離されました。
   • これは、reflect.Call以外の文脈（例えば、パニック時のdefer関数の呼び出しなど）でスタックを拡張する必要がある場合に使用されます。

4. TestBigArgsの意義:

   • このテストは、reflect.Callが非常に大きな引数（1GB以上）を扱う際に、意図的にパニックを引き起こすことを検証します。これは、無限に大きな引数を許容するのではなく、現実的な上限を設定し、その上限を超えた場合に明確なエラー（パニック）を発生させるという設計判断を反映しています。

この変更により、reflect.Callはより予測可能で効率的な動作をするようになり、Goのリフレクション機能の堅牢性が向上しました。

関連リンク

• Go言語のreflectパッケージ: https://pkg.go.dev/reflect
• Goのスタック管理に関する議論 (古い情報も含む): https://go.dev/doc/articles/go_mem.html (Goのメモリモデルに関する一般的な情報)

参考にした情報源リンク

• Goのコミット履歴: https://github.com/golang/go/commits/master
• Goのコードレビューシステム (Gerrit): https://go-review.googlesource.com/ (コミットメッセージに記載されているCLリンクから詳細な議論を追うことができます)
• Goのランタイムに関するドキュメントやソースコード。