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

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

このコミットは、Go言語の reflect パッケージにおける重要な変更を導入しています。具体的には、reflect.callXX ルーチンが makeFuncStub および methodValueCall を直接呼び出すのではなく、これらのルーチンの動作を reflect.call 関数内にインライン化することで、正確なガベージコレクション（GC）とスタックコピーの問題を解決することを目的としています。これにより、関数呼び出し時の引数のメモリレイアウトに関する不整合が解消され、ランタイムの安定性と効率が向上します。

コミット

  • コミットハッシュ: 85138da832f8740bee9241e80acb291a4954a10a
  • Author: Keith Randall khr@golang.org
  • Date: Mon Dec 2 13:36:50 2013 -0800

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

https://github.com/golang/go/commit/85138da832f8740bee9241e80acb291a4954a10a

元コミット内容

reflect: prevent the callXX routines from calling makeFuncStub
and methodValueCall directly.  Instead, we inline their behavior
inside of reflect.call.

This change is required because otherwise we have a situation where
reflect.callXX calls makeFuncStub, neither of which knows the
layout of the args passed between them.  That's bad for
precise gc & stack copying.

Fixes #6619.

R=golang-dev, dvyukov, rsc, iant, khr
CC=golang-dev
https://golang.org/cl/26970044

変更の背景

この変更の背景には、Go言語の reflect パッケージが提供する動的な関数呼び出しメカニズムにおける、ガベージコレクション（GC）とスタックコピーの正確性に関する課題がありました。

Goのランタイムは、メモリ管理のために正確なGC（Precise GC）を採用しています。これは、GCが実行される際に、スタックやヒープ上のどのメモリ領域がポインタであり、どのメモリ領域が非ポインタデータであるかを正確に識別できることを意味します。これにより、GCは到達可能なオブジェクトのみをマークし、不要なオブジェクトを解放することができます。また、Goのランタイムは、ゴルーチンのスタックを必要に応じて拡大・縮小するために、スタックのコピーを行うことがあります。この際にも、スタック上のポインタを正確に識別し、それらが指すオブジェクトを適切に更新する必要があります。

問題は、reflect.callXX（Call や CallSlice など、reflect.Value のメソッドを通じて動的に関数を呼び出す内部ルーチン）が、makeFuncStub や methodValueCall といった内部的なスタブ関数を直接呼び出す場合に発生していました。これらのスタブ関数は、reflect パッケージが提供する MakeFunc や MethodByName などによって生成された動的な関数やメソッドの呼び出しを処理するためのものです。

コミットメッセージによると、reflect.callXX と makeFuncStub または methodValueCall の間で引数が渡される際に、どちらのルーチンも引数のメモリレイアウトを正確に把握していなかったという状況がありました。これは、特に可変長の引数やインターフェース型など、メモリ上での表現が複雑な場合に問題となります。引数のレイアウトが不明確であると、GCがスタック上のポインタを正確に識別できず、誤ってポインタではないデータをポインタとして扱ったり、その逆を行ったりする可能性があります。これは、メモリリーク、クラッシュ、またはデータ破損といった深刻なバグにつながる可能性があります。同様に、スタックコピーの際にも、ポインタの正確な位置が分からなければ、コピー後にポインタが不正なアドレスを指すことになり、プログラムの動作が不安定になります。

この問題を解決するため、開発者は reflect.callXX がこれらのスタブ関数を直接呼び出すのをやめ、代わりに makeFuncStub と methodValueCall のロジックを reflect.call 関数内にインライン化するというアプローチを選択しました。これにより、reflect.call 関数が引数のレイアウトを一元的に管理し、GCとスタックコピーの正確性を保証できるようになります。

コミットメッセージに記載されている Fixes #6619 は、この変更が特定のバグ報告（Issue 6619）を修正するものであることを示しています。ただし、Goの公開Issueトラッカーでこの番号のIssueを直接見つけることはできませんでした。これは、内部的なIssue番号であるか、非常に古いIssueである可能性があります。

前提知識の解説

Go言語の reflect パッケージ

reflect パッケージは、Goプログラムが実行時に自身の構造を検査（introspection）し、変更（reflection）するための機能を提供します。これにより、型情報（Type）の取得、値の操作（Value）、動的な関数呼び出し、構造体のフィールドへのアクセスなどが可能になります。

  • reflect.Type: Goの型に関する情報（名前、カテゴリ、メソッドなど）を表します。
  • reflect.Value: Goの値に関する情報（実際の値、型など）を表し、その値を操作するためのメソッドを提供します。
  • Value.Call() / Value.CallSlice(): reflect.Value が関数を表す場合、これらのメソッドを使ってその関数を動的に呼び出すことができます。引数は []reflect.Value のスライスとして渡され、戻り値も []reflect.Value のスライスとして返されます。
  • reflect.MakeFunc(): 任意の関数シグネチャを持つ新しい関数を動的に作成します。この関数は、内部的に makeFuncStub と呼ばれるスタブ関数を生成し、実際のロジックはユーザーが提供する func([]reflect.Value) []reflect.Value 型の関数で実装されます。
  • Value.MethodByName(): 構造体やインターフェースのメソッドを名前で取得し、reflect.Value として返します。このメソッドもまた、内部的に methodValueCall と呼ばれるスタブ関数を生成し、実際のメソッド呼び出しを処理します。

Go言語のガベージコレクション (GC)

Goのランタイムは、自動メモリ管理のために並行マーク＆スイープ方式のガベージコレクタを使用しています。

  • 正確なGC (Precise GC): GoのGCは正確なGCです。これは、GCがメモリ上のどのワードがポインタであり、どのワードが単なる整数や浮動小数点数などの非ポインタデータであるかを正確に識別できることを意味します。これにより、GCは誤って非ポインタデータをポインタとして解釈し、到達不能なオブジェクトを保持し続けたり（メモリリーク）、逆にポインタを非ポインタとして解釈し、到達可能なオブジェクトを誤って解放したり（クラッシュやデータ破損）するのを防ぎます。正確なGCを実現するためには、コンパイラとランタイムが密接に連携し、型情報に基づいてメモリレイアウトを正確に把握する必要があります。
  • スタックコピー: Goのゴルーチンは、必要に応じてスタックサイズを動的に変更します。スタックが不足した場合、ランタイムはより大きな新しいスタックを割り当て、古いスタックの内容を新しいスタックにコピーします。この際、スタック上のポインタは、コピー先の新しいアドレスを指すように更新される必要があります。ポインタの正確な位置と、それが指すオブジェクトの型情報がなければ、このプロセスは正しく実行できません。

makeFuncStub と methodValueCall

これらはGoの reflect パッケージの内部的なスタブ関数です。

  • makeFuncStub: reflect.MakeFunc を使って動的に作成された関数が呼び出されたときに、実際のユーザー定義のロジック（func([]reflect.Value) []reflect.Value 型の関数）に引数を渡し、戻り値を受け取るための仲介役として機能します。
  • methodValueCall: reflect.Value.MethodByName などで取得されたメソッドが呼び出されたときに、レシーバ（メソッドが属するオブジェクト）と引数を実際のメソッドに渡し、戻り値を受け取るための仲介役として機能します。

これらのスタブ関数は、動的な呼び出しの柔軟性を提供しますが、その実装が reflect.callXX と独立していると、引数のメモリレイアウトに関する情報共有が不十分になり、GCやスタックコピーの正確性に問題が生じる可能性がありました。

技術的詳細

このコミットの技術的詳細の核心は、reflect.call 関数が makeFuncStub と methodValueCall の特殊なケースを直接処理するように変更された点にあります。以前は、reflect.call はこれらのスタブ関数を通常のGo関数として扱い、引数をスタックにパックし、呼び出しを行い、戻り値をアンパックしていました。しかし、この方法では、reflect.call とスタブ関数の間で引数のメモリレイアウトに関する共通の理解が不足していました。

新しいアプローチでは、reflect.call の内部で、呼び出し対象の関数ポインタが makeFuncStub または methodValueCall のいずれかであるかをチェックします。

  1. makeFuncStub のインライン化:

    • reflect.call は、呼び出し対象の関数ポインタが makeFuncStubCode と一致するかどうかをチェックします。
    • もし一致した場合、それは reflect.MakeFunc によって作成された動的な関数であることがわかります。
    • この場合、reflect.call は通常の引数のパック/アンパック処理をスキップし、代わりに makeFuncImpl 構造体から直接ユーザー定義の関数 (x.fn) を呼び出します。この x.fn は func([]reflect.Value) []reflect.Value 型であり、reflect.call は既に []reflect.Value 形式で引数を受け取っているため、余分な変換なしに直接呼び出すことができます。これにより、引数のメモリレイアウトに関する不整合が解消されます。

  2. methodValueCall のインライン化:

    • 同様に、reflect.call は呼び出し対象の関数ポインタが methodValueCallCode と一致するかどうかをチェックします。
    • もし一致した場合、それは reflect.Value.MethodByName などで取得されたメソッドであることがわかります。
    • この場合、reflect.call は methodValue 構造体からレシーバ (y.rcvr) とメソッド情報 (y.method) を抽出し、methodReceiver ヘルパー関数を使って実際のターゲット関数ポインタ (fn) とレシーバの値 (rcvr) を取得します。
    • そして、引数スライス args の先頭にレシーバを挿入し、残りの引数をシフトします。これにより、メソッド呼び出しに必要なレシーバが正しく引数として渡されます。
    • その後、reflect.call は通常の call ルーチンを呼び出して、実際のメソッドを直接実行します。ここでも、引数のレイアウトに関する問題が回避されます。

この変更により、reflect.call は動的な関数/メソッド呼び出しの際に、引数のメモリレイアウトを完全に制御できるようになります。これにより、GCがスタック上のポインタを正確に識別し、スタックコピーが安全に実行されることが保証されます。

また、この変更には新しいテストケースが追加されています。TestReflectFuncTraceback と TestReflectMethodTraceback は、それぞれ MakeFunc で作成された関数と MethodByName で取得されたメソッドの呼び出し中に runtime.GC() を実行し、GCが正しく動作することを確認します。これは、このコミットが解決しようとしているGCとスタックコピーの問題を直接検証するためのものです。

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

このコミットによる主要なコード変更は、src/pkg/reflect/value.go と src/pkg/reflect/all_test.go の2つのファイルにあります。

src/pkg/reflect/value.go

  • 新しいグローバル変数:

    +var makeFuncStubFn = makeFuncStub
+var makeFuncStubCode = **(**uintptr)(unsafe.Pointer(&makeFuncStubFn))
+var methodValueCallFn = methodValueCall
+var methodValueCallCode = **(**uintptr)(unsafe.Pointer(&methodValueCallFn))

    makeFuncStub と methodValueCall の関数ポインタを uintptr として取得し、比較のために使用します。

  • Value.call メソッド内の変更:

    // If target is makeFuncStub, short circuit the unpack onto stack /
// pack back into []Value for the args and return values.  Just do the
// call directly.
// We need to do this here because otherwise we have a situation where
// reflect.callXX calls makeFuncStub, neither of which knows the
// layout of the args.  That's bad for precise gc & stack copying.
x := (*makeFuncImpl)(fn)
if x.code == makeFuncStubCode {
    return x.fn(in)
}

    makeFuncStub のケースを検出し、直接 x.fn(in) を呼び出すことで、引数のパック/アンパックをスキップします。

    // If the target is methodValueCall, do its work here: add the receiver
// argument and call the real target directly.
// We need to do this here because otherwise we have a situation where
// reflect.callXX calls methodValueCall, neither of which knows the
// layout of the args.  That's bad for precise gc & stack copying.
y := (*methodValue)(fn)
if y.fn == methodValueCallCode {
    _, fn, rcvr = methodReceiver("call", y.rcvr, y.method)
    args = append(args, unsafe.Pointer(nil))
    copy(args[1:], args)
    args[0] = unsafe.Pointer(rcvr)
    ptr = unsafe.Pointer(&args[0])
    off += ptrSize
    size += ptrSize
}

    methodValueCall のケースを検出し、レシーバを引数リストに追加し、実際のメソッドを直接呼び出すための準備をします。

src/pkg/reflect/all_test.go

  • 新しいテスト関数: 
    func GCFunc(args []Value) []Value {
    runtime.GC()
    return []Value{}
}

func TestReflectFuncTraceback(t *testing.T) {
    f := MakeFunc(TypeOf(func() {}), GCFunc)
    f.Call([]Value{})
}

func (p Point) GCMethod(k int) int {
    runtime.GC()
    return k + p.x
}

func TestReflectMethodTraceback(t *testing.T) {
    p := Point{3, 4}
    m := ValueOf(p).MethodByName("GCMethod")
    i := ValueOf(m.Interface()).Call([]Value{ValueOf(5)})[0].Int()
    if i != 8 {
        t.Errorf("Call returned %d; want 8", i)
    }
}
    MakeFunc と MethodByName を使用した動的な関数/メソッド呼び出し中に runtime.GC() を実行し、GCが正しく動作するかを検証するテストが追加されています。

コアとなるコードの解説

src/pkg/reflect/value.go の変更

  1. makeFuncStubFn, makeFuncStubCode, methodValueCallFn, methodValueCallCode: これらのグローバル変数は、reflect パッケージの内部的なスタブ関数である makeFuncStub と methodValueCall の関数ポインタを uintptr 型で取得するために導入されました。uintptr はポインタを整数として扱うことができる型であり、関数ポインタの比較に利用されます。unsafe.Pointer を介して型変換を行うことで、Goの型システムを迂回して低レベルなポインタ操作を可能にしています。これにより、reflect.call 関数内で、呼び出し対象の関数がこれらの特定のスタブ関数であるかどうかを効率的にチェックできます。

  2. Value.call メソッド内の条件分岐: Value.call メソッドは、reflect.Value が表す関数やメソッドを実際に呼び出すための内部的なルーチンです。このメソッドの冒頭に、呼び出し対象の関数ポインタ (fn) が makeFuncStubCode または methodValueCallCode と一致するかどうかをチェックする新しい条件分岐が追加されました。

    • makeFuncStub のケース: x := (*makeFuncImpl)(fn): fn (関数ポインタ) を makeFuncImpl 型のポインタに型アサートしています。makeFuncImpl は reflect.MakeFunc によって作成された動的な関数の内部表現であり、実際のユーザー定義の関数 (x.fn) を含んでいます。 if x.code == makeFuncStubCode: makeFuncImpl 構造体内の code フィールドが makeFuncStubCode と一致する場合、それは reflect.MakeFunc によって生成された関数であることが確定します。 return x.fn(in): この場合、reflect.call は通常の引数のパック/アンパック処理（Goの関数呼び出し規約に合わせたスタックへの引数配置）をスキップし、x.fn を直接呼び出します。x.fn は func([]reflect.Value) []reflect.Value 型であり、reflect.call が既に in []Value として引数を受け取っているため、余分な変換なしに直接呼び出すことができます。これにより、引数のメモリレイアウトに関する不整合が解消され、GCとスタックコピーの正確性が保証されます。

    • methodValueCall のケース: y := (*methodValue)(fn): fn を methodValue 型のポインタに型アサートしています。methodValue は reflect.Value.MethodByName などで取得されたメソッドの内部表現であり、レシーバ (y.rcvr) とメソッド情報 (y.method) を含んでいます。 if y.fn == methodValueCallCode: methodValue 構造体内の fn フィールドが methodValueCallCode と一致する場合、それは動的に取得されたメソッドであることが確定します。 _, fn, rcvr = methodReceiver("call", y.rcvr, y.method): methodReceiver ヘルパー関数を呼び出して、実際のメソッドの関数ポインタ (fn) と、そのメソッドが呼び出されるべきレシーバの値 (rcvr) を取得します。 args = append(args, unsafe.Pointer(nil)): 引数スライス args の末尾にダミーの要素を追加し、レシーバを挿入するためのスペースを確保します。 copy(args[1:], args): 既存の引数を1つ後ろにシフトします。 args[0] = unsafe.Pointer(rcvr): シフトされた引数スライスの先頭（インデックス0）にレシーバのポインタを配置します。Goのメソッド呼び出し規約では、レシーバは最初の引数として渡されます。 ptr = unsafe.Pointer(&args[0]): 実際の関数呼び出し (call(fn, ptr, uint32(size))) に渡す引数ブロックの先頭ポインタを更新します。 off += ptrSize, size += ptrSize: 引数ブロックのオフセットとサイズを、レシーバの追加分だけ調整します。 この処理により、reflect.call はメソッド呼び出しに必要なレシーバを正しく引数として渡し、実際のメソッドを直接呼び出すことができます。ここでも、引数のメモリレイアウトに関する問題が回避されます。

src/pkg/reflect/all_test.go の変更

追加されたテストは、このコミットが解決しようとしているGCとスタックコピーの問題を直接検証するためのものです。

  • GCFunc と TestReflectFuncTraceback: GCFunc は runtime.GC() を呼び出すだけのシンプルな関数です。 TestReflectFuncTraceback では、reflect.MakeFunc を使って GCFunc をラップした動的な関数 f を作成し、f.Call() を呼び出しています。このテストは、MakeFunc で作成された関数が呼び出されている最中にGCが実行されても、プログラムがクラッシュしたり、不正なメモリ状態になったりしないことを保証します。これは、makeFuncStub のインライン化が正しく機能していることを示します。

  • GCMethod と TestReflectMethodTraceback: Point 型に GCMethod というメソッドを追加しています。このメソッドも runtime.GC() を呼び出します。 TestReflectMethodTraceback では、reflect.ValueOf(p).MethodByName("GCMethod") を使って GCMethod を動的に取得し、Call メソッドで呼び出しています。このテストは、動的に取得されたメソッドが呼び出されている最中にGCが実行されても、プログラムが正しく動作し、期待される結果（8）を返すことを確認します。これは、methodValueCall のインライン化が正しく機能していることを示します。

これらのテストは、動的な関数/メソッド呼び出しのコンテキストでGCが安全に実行できることを確認するための重要な検証ステップです。

関連リンク

参考にした情報源リンク

  • コミットメッセージと差分 (/home/orange/Project/comemo/commit_data/17901.txt)
  • Go言語の reflect パッケージのドキュメント (一般的な知識として)
  • Go言語のガベージコレクションに関する一般的な情報 (一般的な知識として)
  • Issue #6619 については、公開されているGoのIssueトラッカーでは直接関連する情報を見つけることができませんでした。これは内部的なIssueであるか、非常に古いIssueである可能性があります。