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

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

このコミットは、Goランタイムにおけるスタックアロケータの変更を元に戻すものです。具体的には、以前のコミット（CL 104200047 / 318b04f28372）によって導入された、スタックアロケータをmallocgc（ヒープアロケータ）から分離する試みを巻き戻しています。この分離は、mallocをGo言語で実装するための前提条件として計画されていましたが、Windows環境およびGoのレース検出器に問題を引き起こしたため、このコミットで元に戻されました。

コミット

commit 3cf83c182af504bcffb82f3fc78a0c8b0ffb3aaa
Author: Keith Randall <khr@golang.org>
Date:   Mon Jun 30 19:48:08 2014 -0700

    undo CL 104200047 / 318b04f28372
    
    Breaks windows and race detector.
    TBR=rsc
    
    ««« original CL description
    runtime: stack allocator, separate from mallocgc
    
    In order to move malloc to Go, we need to have a
    separate stack allocator.  If we run out of stack
    during malloc, malloc will not be available
    to allocate a new stack.
    
    Stacks are the last remaining FlagNoGC objects in the
    GC heap.  Once they are out, we can get rid of the
    distinction between the allocated/blockboundary bits.
    (This will be in a separate change.)
    
    Fixes #7468
    Fixes #7424
    
    LGTM=rsc, dvyukov
    R=golang-codereviews, dvyukov, khr, dave, rsc
    CC=golang-codereviews
    https://golang.org/cl/104200047
    »»»
    
    TBR=rsc
    CC=golang-codereviews
    https://golang.org/cl/101570044

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

https://github.com/golang/go/commit/3cf83c182af504bcffb82f3fc78a0c8b0ffb3aaa

元コミット内容

このコミットが元に戻した元の変更（CL 104200047 / 318b04f28372）の目的は以下の通りでした。

  • スタックアロケータの分離: malloc（メモリ確保関数）をGo言語で実装するために、スタックアロケータを既存のヒープアロケータであるmallocgcから分離すること。これは、malloc実行中にスタックが不足した場合に、新しいスタックを確保できなくなる問題を回避するためでした。
  • FlagNoGCオブジェクトからのスタックの除外: スタックは、GCヒープ内で最後に残ったFlagNoGC（ガベージコレクションの対象外）オブジェクトでした。スタックをFlagNoGCから除外することで、割り当て済み/ブロック境界ビット間の区別をなくし、メモリ管理をより統一的にすることを目指していました。
  • 関連するIssueの修正: Issue #7468 および #7424 の修正を意図していました。

変更の背景

元のコミット（CL 104200047）は、Goランタイムのメモリ管理を近代化し、将来的にmallocをGo言語で実装するための重要なステップでした。しかし、この変更は意図しない副作用をもたらしました。コミットメッセージに明記されている通り、「Windowsとレース検出器を壊した」ため、安定性を優先してこの変更を元に戻す必要が生じました。

具体的には、スタックアロケータをmallocgcから分離し、スタックをGC対象に含めようとしたことで、以下の問題が発生したと考えられます。

  • Windows環境での問題: Goのgoroutineスタックは動的に伸縮しますが、WindowsのOSスレッドスタックは固定サイズです。この間の相互作用、特にC言語ライブラリやWindows APIとの連携において、スタック管理の変更が予期せぬ動作やクラッシュを引き起こした可能性があります。Goの動的スタックとWindowsの固定スタックの間の不整合が、新しいスタックアロケータの設計と衝突したと考えられます。
  • レース検出器の問題: Goのレース検出器は、メモリへのアクセスを詳細に計測し、データ競合を検出します。スタックアロケータの変更が、この計測メカニズムと競合したり、スタック上のメモリアクセスの追跡方法に影響を与えたりしたことで、レース検出器が正しく機能しなくなった可能性があります。特に、スタックの成長や新しいスタックの割り当て時に、ライトバリアが正しく適用されない問題（元のCLの目的でもあった「スタックバリアの修正」）が、レース検出器の誤動作につながった可能性も考えられます。

これらの問題は、Goランタイムの安定性とデバッグの容易さに深刻な影響を与えるため、元の変更を一時的に巻き戻し、より堅牢な解決策を模索する判断が下されました。

前提知識の解説

このコミットの変更内容を理解するためには、Goランタイムのメモリ管理、特にスタックとヒープの概念、ガベージコレクション（GC）、そしてスタックの動的な性質に関する知識が不可欠です。

  • Goのメモリ管理（スタックとヒープ）

    • スタック (Stack): 関数呼び出しのフレーム、ローカル変数、関数引数、戻りアドレスなどを格納するために使用されるメモリ領域です。Goでは、各goroutineが独自のスタックを持っています。スタックの割り当てと解放はコンパイラによって自動的に行われ、非常に高速です。スタックはLIFO（Last-In, First-Out）の原則に従って動作し、関数が呼び出されるとスタックフレームがプッシュされ、関数から戻るとポップされます。Goのスタックは動的に伸縮する特徴があり、必要に応じて自動的に拡大・縮小します。
    • ヒープ (Heap): プログラムの実行中に動的にメモリを割り当てるために使用されるメモリ領域です。コンパイル時にサイズが不明なデータや、関数のスコープを超えて存続する必要があるデータ（例: スライス、マップ、チャネル、構造体のポインタなど）はヒープに割り当てられます。ヒープメモリはGoランタイムのガベージコレクタ（GC）によって管理され、不要になったメモリは自動的に解放されます。スタックに比べて割り当てと解放のオーバーヘッドが大きいです。
    • エスケープ解析 (Escape Analysis): Goコンパイラは、変数がスタックに割り当てられるべきか、ヒープに「エスケープ」して割り当てられるべきかを決定するためにエスケープ解析を行います。変数の寿命が関数呼び出しを超えて延長される場合や、そのアドレスが他の場所で使用される場合、その変数はヒープに割り当てられます。

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

    • Goは、並行マーク＆スイープ方式のガベージコレクタを採用しています。これにより、アプリケーションの実行を長時間停止させることなく（Stop-The-World: STW時間を最小限に抑えながら）、不要なヒープメモリを効率的に回収します。
    • ハイブリッドライトバリア (Hybrid Write Barrier): GoのGCは、Yuasaの削除バリアとDijkstraの挿入バリアを組み合わせたハイブリッドライトバリアを使用しています。これは、GCが並行して動作している間にポインタの変更を正確に追跡し、ライブオブジェクトが誤って回収されるのを防ぐための重要なメカニズムです。
    • FlagNoGC: Goランタイム内部で、ガベージコレクションの対象外としてマークされる特定のオブジェクトやメモリ領域が存在します。これらは通常、GCのサイクルとは独立して管理されるか、GCのロジックに含めるのが複雑な低レベルのランタイム構造体です。元のCLでは、スタックがこのFlagNoGCオブジェクトの最後の残りのカテゴリであると述べられていました。

  • Goランタイムのメモリ管理構造体

    • MHeap: Goランタイム全体のヒープを管理する構造体です。メモリの割り当て、解放、およびガベージコレクションの主要な調整を行います。
    • MSpan: 連続したページ（メモリブロック）のまとまりを表す構造体です。ヒープはMSpanの集合として管理されます。MSpanは、その状態（例: MSpanInUse, MSpanFree）によって、現在使用中か、空き状態か、あるいは特定の目的（元のCLではスタック用）に割り当てられているかを示します。
    • MCache: 各P（プロセッサ、Goスケジューラにおける論理CPU）に紐付けられたローカルなメモリキャッシュです。小さなオブジェクトの割り当てを高速化するために使用されます。
    • MCentral: 特定のサイズクラスのMSpanを管理する中央リストです。MCacheがメモリを使い果たした場合、MCentralからMSpanを取得します。

  • Windows環境でのスタック管理の課題

    • Goのgoroutineは軽量であり、そのスタックは動的に伸縮します。しかし、GoコードがCgoを介してCコードを呼び出す場合や、直接Windows APIと対話する場合、Goランタイムは固定サイズのOSスレッドスタックに切り替える必要があります。Goの動的なスタック管理とOSの固定スタック管理の間の不一致は、特にWindows環境でスタックオーバーフローやクラッシュの原因となることが歴史的にありました。

  • Goレース検出器

    • Goレース検出器は、Goプログラムにおけるデータ競合（複数のgoroutineが同じメモリ位置に同時にアクセスし、少なくとも1つのアクセスが書き込みであり、適切な同期が行われていない場合に発生するバグ）を特定するための強力なツールです。-raceフラグを付けてビルドすることで有効になります。レース検出器は、メモリアクセスを計測し、追加のデータ構造を維持することで動作するため、プログラムの実行時間とメモリ使用量に大きなオーバーヘッドをもたらします。スタック上のメモリアクセスも監視対象となります。

技術的詳細

このコミットは、元のCL 104200047によって導入されたスタックアロケータの分離と、それに伴うメモリ管理の変更を完全に元に戻すものです。元のCLは、スタックをGCヒープの一部として扱い、FlagNoGCオブジェクトから除外することで、メモリ管理の統一性を高めようとしました。しかし、このアプローチはWindows環境でのスタックの挙動とレース検出器の動作に悪影響を与えました。

この「undo」コミットの技術的なポイントは以下の通りです。

  1. スタックアロケータの独立性の回復: 元のCLは、スタックをmallocgcから分離し、独自のスタックアロケータを導入しようとしました。しかし、このundoコミットは、スタックの割り当てを再びヒープの一般的な割り当てメカニズム（ただし、GC対象外の特別な扱い）に戻し、スタック専用のキャッシュメカニズム（stackcache）を復活させました。これにより、スタックの割り当てと解放が、ヒープのGCサイクルとはある程度独立して行われるようになります。
  2. MSpanStack状態の削除の巻き戻し: 元のCLでは、MSpanの状態からMSpanStackが削除され、スタックもMSpanInUseとして扱われるように変更されていました。このundoコミットでは、MSpanStack状態の概念自体が削除され、スタック用のMSpanもMSpanInUseとして扱われるようになります。これは、スタックがGCヒープの通常のオブジェクトとして扱われるという元のCLの意図とは逆の方向性ですが、安定性を優先した結果です。ただし、mheap.cの変更を見ると、MSpanStackという状態は完全に削除され、MSpanInUseが割り当てられたスパンの唯一の状態となっています。これは、スタックがヒープから割り当てられるものの、その管理方法が特殊であることを示唆しています。
  3. Stktop構造体へのmallocedフラグの再導入: スタックがヒープから割り当てられたものか、それとも特別なスタックアロケータから割り当てられたものかを区別するために、Stktop構造体にmallocedブーリアンフィールドが再導入されました。これは、スタックの解放時に適切な処理（ヒープからの解放か、スタックキャッシュへの返却か）を行うために必要です。
  4. スタックキャッシュの復活: runtime.hとstack.cの変更から、各M（OSスレッド）にローカルなスタックキャッシュ（stackcache）が復活していることがわかります。これは、頻繁なスタックの割り当てと解放のパフォーマンスを向上させるためのものです。グローバルなスタックキャッシュ（stackcachemuとstackcache）も存在し、Mのローカルキャッシュが不足した場合に利用されます。
  5. GCとの相互作用の簡素化: 元のCLが試みたスタックとGCのより密接な統合は、ライトバリアの複雑さを増し、Windowsやレース検出器で問題を引き起こしました。このundoコミットは、スタックのメモリ管理をGCの主要なパスからある程度切り離すことで、これらの問題を回避しています。スタックは依然としてGCヒープの一部から割り当てられる可能性がありますが、そのライフサイクル管理はより独立したメカニズムによって行われます。

このコミットは、機能追加や最適化よりも、Goランタイムの堅牢性と安定性を維持することを優先した典型的な例と言えます。複雑な低レベルのメモリ管理において、理論的にクリーンな設計が常に実用的な安定性をもたらすとは限らないことを示しています。

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

このコミットは、主にGoランタイムのメモリ管理とスタック管理に関連する複数のファイルにわたる変更を元に戻しています。

  • src/pkg/runtime/malloc.h:
    • StackCacheSize, NumStackOrdersといったスタックキャッシュ関連の定数定義が削除されました。
    • StackFreeList構造体の定義が削除されました。
    • MCache構造体からstackcacheフィールドが削除されました。
    • MSpanの状態定義からMSpanStackが削除され、MSpanInUseが割り当て済みスパンの唯一の状態となりました。
    • runtime·MHeap_AllocStackおよびruntime·MHeap_FreeStack関数のプロトタイプが削除されました。
  • src/pkg/runtime/mcache.c:
    • runtime·stackcache_clear(c)の呼び出しが削除されました。これは、MCacheのスタックキャッシュをクリアする関数でした。
  • src/pkg/runtime/mcentral.c:
    • MSpanがリストにないことを確認するアサーションが削除されました。
  • src/pkg/runtime/mem.go:
    • MemStats構造体内のStackInuseフィールドのコメントが「bytes used by stack allocator」から「bootstrap stacks」に戻されました。
  • src/pkg/runtime/mgc0.c:
    • GCのマークフェーズにおけるMSpanStack状態のチェックが削除されました。
    • runtime·stackcache_clear(c)の呼び出しが削除されました。
    • runtime·updatememstats関数におけるmstats.stacks_inuseの計算ロジックが変更され、mp->stackinuse*FixedStackの合計が使用されるようになりました。
    • runtime·ReadMemStats関数から、スタック関連の統計をヒープ統計から分離するロジックが削除されました。
  • src/pkg/runtime/mheap.c:
    • MHeap_AllocSpanLocked関数がMHeap_AllocLockedに統合され、スタック専用の割り当てロジックが削除されました。
    • runtime·MHeap_AllocStack関数が削除されました。
    • mheap_alloc関数がruntime·MHeap_Allocに統合され、GスタックとMスタックでの呼び出しを区別するロジックが削除されました。
    • MHeap_FreeSpanLocked関数がMHeap_FreeLockedに統合され、MSpanStack状態のチェックが削除されました。
    • runtime·MHeap_FreeStack関数が削除されました。
    • MSpanの結合ロジックにおいて、MSpanStack状態のチェックが削除されました。
    • scavenge関数およびruntime·MHeap_Scavenger関数から、mcallを使用したGスタックからMスタックへの切り替えロジックが削除され、直接Mスタックで実行されるようになりました。
    • runtime·MHeap_SplitSpan関数が追加されましたが、これは元のCLとは直接関係なく、このコミットで導入された新しい機能です。
  • src/pkg/runtime/proc.c:
    • runtime·schedinit関数からruntime·stackinit()の呼び出しが削除されました。
    • gfput関数で、スタックがmallocedかどうかをチェックするロジックが復活しました。
  • src/pkg/runtime/runtime.h:
    • StackCacheSize, StackCacheBatchといったスタックキャッシュ関連の定数が再導入されました。
    • M構造体にstackinuse, stackcachepos, stackcachecnt, stackcacheといったスタックキャッシュ関連のフィールドが再導入されました。
    • M構造体からscalarargとptrargフィールドが削除されました。
    • Stktop構造体にmallocedフィールドが再導入されました。
    • runtime·stackinit関数のプロトタイプが削除されました。
  • src/pkg/runtime/stack.c:
    • スタックプール（stackpool）と関連するロック（stackpoolmu）の定義が削除されました。
    • runtime·stackinit関数が削除されました。
    • poolalloc、poolfreeといったスタックプールからの割り当て・解放関数が削除されました。
    • stackcacherefill、stackcachereleaseといったMCacheのスタックキャッシュを操作する関数が、よりシンプルなグローバルキャッシュのロジックに置き換えられました。
    • runtime·stackcache_clear関数が削除されました。
    • runtime·stackalloc関数とruntime·stackfree関数が大幅に変更され、スタックキャッシュとmallocedフラグを使用する以前のロジックに戻されました。
  • src/pkg/runtime/stack_test.go:
    • 元のCLで追加されたTestStackCacheテスト関数が削除されました。

コアとなるコードの解説

このコミットの核心は、Goランタイムのスタック管理を、元のCLが導入しようとした「ヒープとの統合」から、以前の「独立したキャッシュベースのアロケータ」に戻すことです。

  1. スタックキャッシュの復活と役割分担:

    • 元のCLは、スタックをヒープの一般的なMSpanInUseとして扱い、mallocgcと統合しようとしました。しかし、このコミットでは、runtime.hとstack.cでStackCacheSizeやStackCacheBatchといった定数、そしてM構造体内のstackcache関連フィールドが復活しています。これは、各M（OSスレッド）が小さなスタックセグメントのローカルキャッシュを持つことを意味します。
    • stack.cのruntime·stackallocとruntime·stackfree関数は、このローカルキャッシュとグローバルなスタックキャッシュ（stackcacheとstackcachemu）を利用するように変更されました。これにより、頻繁に割り当て・解放される小さなスタックは、高速なキャッシュから供給され、ヒープアロケータのオーバーヘッドを回避します。
    • FixedStackサイズのスタックはキャッシュから供給され、それより大きなスタックはmallocgcから割り当てられるという、以前のハイブリッドなアプローチに戻りました。

  2. MSpanStack状態の削除とmallocedフラグの重要性:

    • 元のCLはMSpanStack状態を削除し、スタックもMSpanInUseとして扱おうとしました。このundoコミットでもMSpanStack状態は削除されたままですが、Stktop構造体にmallocedブーリアンフィールドが再導入されました。
    • このmallocedフラグは、スタックがFixedStackサイズでスタックキャッシュから割り当てられたものか（mallocedがfalse）、それともmallocgc（ヒープ）から割り当てられたものか（mallocedがtrue）を区別するために使用されます。
    • runtime·stackfree関数では、このmallocedフラグに基づいて、スタックをスタックキャッシュに戻すか、runtime·free（ヒープ解放）を呼び出すかを決定します。これにより、スタックの割り当て元に応じた適切な解放処理が保証されます。

  3. mheap.cとmgc0.cの変更:

    • mheap.cでは、スタック専用の割り当て・解放関数（MHeap_AllocStack, MHeap_FreeStack）が削除され、一般的なMHeap_AllocとMHeap_Freeが使用されるようになりました。これは、スタックがヒープから割り当てられるという事実を反映していますが、その管理はstack.cのロジックによって特殊化されます。
    • mgc0.cでは、GCの統計更新やマークフェーズからスタックキャッシュ関連のロジックが削除され、GCがスタックの内部管理に直接関与しない以前の状態に戻りました。mstats.stacks_inuseの計算も、Mごとのstackinuseフィールド（これはキャッシュ内のスタック数を追跡）に基づいて行われるようになりました。

  4. テストの巻き戻し:

    • stack_test.goからTestStackCacheが削除されたことは、元のCLが導入したスタックキャッシュの新しいテストが不要になったことを示しています。これは、その機能が完全に元に戻されたことの明確な証拠です。

総じて、このコミットは、Goランタイムのスタック管理を、よりシンプルで実績のあるメカニズムに戻すことで、Windows環境での互換性問題とレース検出器の誤動作を解決しました。これは、パフォーマンスの最適化や設計の統一性よりも、安定性と堅牢性を優先した結果であり、Goランタイム開発における実用主義的なアプローチを反映しています。

関連リンク

  • 元コミット (CL 104200047):

参考にした情報源リンク