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

このコミットは、Go言語のランタイムにおけるセマフォテーブルのガベージコレクタからの隠蔽に関する変更です。具体的には、セマフォテーブルがガベージコレクタによって誤って解放されることを防ぐための修正が行われています。

コミット

commit 35724c1aa5f9370093851c92fb61b482260bb834
Author: Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Date:   Tue Sep 18 14:30:01 2012 -0400

    runtime: hide the semaphore table from garbage collector
    
    R=rsc, dvyukov, dave
    CC=golang-dev
    https://golang.org/cl/6528043

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

https://github.com/golang/go/commit/35724c1aa5f9370093851c92fb61b482260bb834

元コミット内容

runtime: hide the semaphore table from garbage collector

R=rsc, dvyukov, dave
CC=golang-dev
https://golang.org/cl/6528043

変更の背景

Go言語のランタイムは、並行処理を効率的に管理するためにセマフォを使用します。セマフォは、複数のゴルーチン（Goの軽量スレッド）が共有リソースにアクセスする際の同期メカニズムとして機能します。このコミットが行われた背景には、Goのガベージコレクタ（GC）がセマフォテーブルを誤ってヒープ上のポインタとして認識し、その結果、テーブルが不適切に解放されてしまう可能性があったことが挙げられます。

セマフォテーブルは、ランタイムの非常に低レベルな部分であり、常に利用可能である必要があります。もしGCがこのテーブルを「到達不可能」と判断して解放してしまった場合、ランタイムの動作が不安定になったり、クラッシュしたりする重大な問題を引き起こす可能性があります。この変更は、このような潜在的な問題を回避し、ランタイムの堅牢性を向上させることを目的としています。

前提知識の解説

このコミットを理解するためには、以下の概念についての知識が必要です。

• Goランタイム: Goプログラムの実行を管理する低レベルなシステム。スケジューラ、ガベージコレクタ、メモリ管理などが含まれます。
• ガベージコレクタ (GC): プログラムが動的に確保したメモリのうち、もはや使用されていない（到達不可能な）領域を自動的に解放するシステム。GoのGCは、並行かつ低遅延で動作するように設計されています。
• セマフォ: 並行プログラミングにおける同期プリミティブの一つ。共有リソースへのアクセスを制御するために使用され、特定のリソースに同時にアクセスできるスレッド（またはゴルーチン）の数を制限します。Goのランタイムでは、内部的な同期メカニズムとしてセマフォが利用されます。
• ヒープとスタック:
  • ヒープ: プログラム実行中に動的にメモリを確保する領域。GCの主な対象となります。
  • スタック: 関数呼び出しやローカル変数などが一時的に格納されるメモリ領域。GCの対象外です。
• #pragma ディレクティブ: C言語やC++において、コンパイラに対して特定の指示を与えるためのプリプロセッサディレクティブ。Goのランタイムコードの一部はC言語で書かれており、Goのツールチェーンによってコンパイルされる際にこれらのディレクティブが解釈されます。このコミットで登場する #pragma dataflag は、Goのコンパイラ/リンカに対するGo固有の拡張ディレクティブです。

技術的詳細

このコミットの核心は、Goランタイムが使用するセマフォテーブルをガベージコレクタの監視対象から外すことです。これは、src/pkg/runtime/sema.goc ファイル内の semtable というグローバル配列に対して行われます。

変更前は、semtable は単なる static union の配列として定義されていました。GoのGCは、ヒープ上のポインタを追跡して到達可能なオブジェクトを特定します。もし semtable がポインタを含む構造体として扱われたり、GCがそのメモリ領域をヒープの一部と誤認したりした場合、GCのサイクル中に誤ってスキャンされ、その内容がポインタではないにもかかわらずポインタとして解釈されたり、最悪の場合、テーブル自体が解放されたりするリスクがありました。

この問題を解決するために、以下の2つの主要な変更が導入されました。

1. #pragma dataflag 16 の導入: #pragma dataflag 16 は、Goのコンパイラ/リンカに対する特別な指示です。dataflag 16 は、特定のデータセクション（この場合は semtable 配列）に「ポインタを含まない (no pointers)」というマークを付けます。これにより、ガベージコレクタは semtable のメモリ領域をスキャンする必要がないと認識し、その内容をポインタとして解釈しようとしなくなります。これは、GCの誤動作を防ぐ上で非常に重要です。semtable は、セマフォのルート構造体 SemaRoot を含んでいますが、これはポインタではなく、GCが追跡する必要のないデータ構造です。

2. Sema s; のスタック割り当てに関するコメント追加: runtime·semacquire 関数内で宣言されている Sema s; 変数について、// Needs to be allocated on stack, otherwise garbage collector could deallocate it というコメントが追加されました。これは、Sema 構造体がセマフォの内部状態を保持するものであり、もしこれがヒープに割り当てられた場合、GCによって誤って解放される可能性があることを示唆しています。Goのコンパイラは、変数をスタックに割り当てるかヒープに割り当てるかを自動的に決定しますが、このコメントは、開発者に対してこの変数のメモリ割り当ての重要性を強調しています。Sema はセマフォの内部表現であり、そのライフサイクルはセマフォ操作と密接に結びついています。スタックに割り当てることで、関数のスコープを抜けると自動的に解放され、GCの介入なしに管理されます。

これらの変更により、semtable はGCの対象外となり、Sema 変数も安全に管理されることで、Goランタイムの安定性と信頼性が向上しました。

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

--- a/src/pkg/runtime/sema.goc
+++ b/src/pkg/runtime/sema.goc
@@ -43,11 +43,13 @@ struct SemaRoot
 // Prime to not correlate with any user patterns.
 #define SEMTABLESZ 251
 
-static union
+union semtable
 {
  	SemaRoot;
  	uint8 pad[CacheLineSize];
-} semtable[SEMTABLESZ];
+};
+#pragma dataflag 16 /* mark semtable as 'no pointers', hiding from garbage collector */
+static union semtable semtable[SEMTABLESZ];
 
 static SemaRoot*
 semroot(uint32 *addr)
@@ -98,7 +100,7 @@ cansemacquire(uint32 *addr)
 void
 runtime·semacquire(uint32 volatile *addr)
 {
-\tSema s;\n+\tSema s;\t// Needs to be allocated on stack, otherwise garbage collector could deallocate it
 \tSemaRoot *root;
 
 \t// Easy case.

コアとなるコードの解説

1. union semtable の定義と #pragma dataflag 16:

   • 変更前は、semtable は匿名 union の配列として直接定義されていました。
   • 変更後、union semtable という名前付きの union が定義され、その後に semtable 配列が宣言されています。
   • 最も重要な変更は、static union semtable semtable[SEMTABLESZ]; の直前に挿入された #pragma dataflag 16 です。このディレクティブは、Goのコンパイラに対して、semtable 配列がポインタを含まないデータであることを明示的に伝えます。これにより、GCは semtable のメモリ領域をスキャンする際に、ポインタの有無を確認する処理をスキップし、誤ってポインタとして解釈したり、不適切に解放したりするリスクを排除します。これは、GCの効率性向上にも寄与します。

2. Sema s; のコメント追加:

   • runtime·semacquire 関数は、セマフォの取得（ロック）を行うランタイム関数です。
   • この関数内で宣言されているローカル変数 Sema s; の行に、// Needs to be allocated on stack, otherwise garbage collector could deallocate it というコメントが追加されました。
   • Sema 構造体は、セマフォの内部状態（例えば、待機中のゴルーチンリストへのポインタなど）を保持する可能性があります。もしこの s がヒープに割り当てられた場合、GCがそのポインタを追跡し、誤って解放してしまう可能性がありました。しかし、ローカル変数としてスタックに割り当てられることで、関数の実行が終了すると自動的に解放され、GCの介入なしに安全に管理されます。このコメントは、この設計意図とGCとの相互作用における重要性を強調しています。

これらの変更は、Goランタイムのメモリ管理とガベージコレクションの正確性を保証し、セマフォのような低レベルな同期プリミティブが安定して機能するために不可欠です。

関連リンク

• Go言語のガベージコレクションに関する公式ドキュメントやブログ記事 (コミット当時の情報にアクセスするのは難しいかもしれませんが、一般的な概念は共通です)
• Go言語のセマフォ実装に関するソースコード (src/runtime/sema.go や src/runtime/sema.goc の現在のバージョン)
• Go言語の go tool compile や go tool link のドキュメント（#pragma ディレクティブに関する情報が含まれる可能性があります）

参考にした情報源リンク

• Go言語の公式リポジトリ: https://github.com/golang/go
• Go言語のコードレビューシステム (Gerrit): https://golang.org/cl/6528043 (元の変更リスト)
• Go言語のガベージコレクションに関する一般的な情報源 (例: Goブログ、Goドキュメント)
• C言語の #pragma ディレクティブに関する一般的な情報源
• Go言語のランタイムに関する技術記事や解説 (特にメモリ管理やGCに焦点を当てたもの)# [インデックス 13862] ファイルの概要

このコミットは、Go言語のランタイムにおけるセマフォテーブルのガベージコレクタからの隠蔽に関する変更です。具体的には、セマフォテーブルがガベージコレクタによって誤って解放されることを防ぐための修正が行われています。

コミット

commit 35724c1aa5f9370093851c92fb61b482260bb834
Author: Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Date:   Tue Sep 18 14:30:01 2012 -0400

    runtime: hide the semaphore table from garbage collector
    
    R=rsc, dvyukov, dave
    CC=golang-dev
    https://golang.org/cl/6528043

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

https://github.com/golang/go/commit/35724c1aa5f9370093851c92fb61b482260bb834

元コミット内容

runtime: hide the semaphore table from garbage collector

R=rsc, dvyukov, dave
CC=golang-dev
https://golang.org/cl/6528043

変更の背景

Go言語のランタイムは、並行処理を効率的に管理するためにセマフォを使用します。セマフォは、複数のゴルーチン（Goの軽量スレッド）が共有リソースにアクセスする際の同期メカニズムとして機能します。このコミットが行われた背景には、Goのガベージコレクタ（GC）がセマフォテーブルを誤ってヒープ上のポインタとして認識し、その結果、テーブルが不適切に解放されてしまう可能性があったことが挙げられます。

セマフォテーブルは、ランタイムの非常に低レベルな部分であり、常に利用可能である必要があります。もしGCがこのテーブルを「到達不可能」と判断して解放してしまった場合、ランタイムの動作が不安定になったり、クラッシュしたりする重大な問題を引き起こす可能性があります。この変更は、このような潜在的な問題を回避し、ランタイムの堅牢性を向上させることを目的としています。

前提知識の解説

このコミットを理解するためには、以下の概念についての知識が必要です。

• Goランタイム: Goプログラムの実行を管理する低レベルなシステム。スケジューラ、ガベージコレクタ、メモリ管理などが含まれます。
• ガベージコレクタ (GC): プログラムが動的に確保したメモリのうち、もはや使用されていない（到達不可能な）領域を自動的に解放するシステム。GoのGCは、並行かつ低遅延で動作するように設計されています。
• セマフォ: 並行プログラミングにおける同期プリミティブの一つ。共有リソースへのアクセスを制御するために使用され、特定のリソースに同時にアクセスできるスレッド（またはゴルーチン）の数を制限します。Goのランタイムでは、内部的な同期メカニズムとしてセマフォが利用されます。
• ヒープとスタック:
  • ヒープ: プログラム実行中に動的にメモリを確保する領域。GCの主な対象となります。
  • スタック: 関数呼び出しやローカル変数などが一時的に格納されるメモリ領域。GCの対象外です。
• #pragma ディレクティブ: C言語やC++において、コンパイラに対して特定の指示を与えるためのプリプロセッサディレクティブ。Goのランタイムコードの一部はC言語で書かれており、Goのツールチェーンによってコンパイルされる際にこれらのディレクティブが解釈されます。このコミットで登場する #pragma dataflag は、Goのコンパイラ/リンカに対するGo固有の拡張ディレクティブです。

技術的詳細

このコミットの核心は、Goランタイムが使用するセマフォテーブルをガベージコレクタの監視対象から外すことです。これは、src/pkg/runtime/sema.goc ファイル内の semtable というグローバル配列に対して行われます。

変更前は、semtable は単なる static union の配列として定義されていました。GoのGCは、ヒープ上のポインタを追跡して到達可能なオブジェクトを特定します。もし semtable がポインタを含む構造体として扱われたり、GCがそのメモリ領域をヒープの一部と誤認したりした場合、GCのサイクル中に誤ってスキャンされ、その内容がポインタではないにもかかわらずポインタとして解釈されたり、最悪の場合、テーブル自体が解放されたりするリスクがありました。

この問題を解決するために、以下の2つの主要な変更が導入されました。

1. #pragma dataflag 16 の導入: #pragma dataflag 16 は、Goのコンパイラ/リンカに対する特別な指示です。dataflag 16 は、特定のデータセクション（この場合は semtable 配列）に「ポインタを含まない (no pointers)」というマークを付けます。これにより、ガベージコレクタは semtable のメモリ領域をスキャンする必要がないと認識し、その内容をポインタとして解釈しようとしなくなります。これは、GCの誤動作を防ぐ上で非常に重要です。semtable は、セマフォのルート構造体 SemaRoot を含んでいますが、これはポインタではなく、GCが追跡する必要のないデータ構造です。

2. Sema s; のスタック割り当てに関するコメント追加: runtime·semacquire 関数内で宣言されている Sema s; 変数について、// Needs to be allocated on stack, otherwise garbage collector could deallocate it というコメントが追加されました。これは、Sema 構造体がセマフォの内部状態を保持するものであり、もしこれがヒープに割り当てられた場合、GCによって誤って解放される可能性があることを示唆しています。Goのコンパイラは、変数をスタックに割り当てるかヒープに割り当てるかを自動的に決定しますが、このコメントは、開発者に対してこの変数のメモリ割り当ての重要性を強調しています。Sema はセマフォの内部表現であり、そのライフサイクルはセマフォ操作と密接に結びついています。スタックに割り当てることで、関数のスコープを抜けると自動的に解放され、GCの介入なしに管理されます。

これらの変更により、semtable はGCの対象外となり、Sema 変数も安全に管理されることで、Goランタイムの安定性と信頼性が向上しました。

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

--- a/src/pkg/runtime/sema.goc
+++ b/src/pkg/runtime/sema.goc
@@ -43,11 +43,13 @@ struct SemaRoot
 // Prime to not correlate with any user patterns.
 #define SEMTABLESZ 251
 
-static union
+union semtable
 {
  	SemaRoot;
  	uint8 pad[CacheLineSize];
-} semtable[SEMTABLESZ];
+};
+#pragma dataflag 16 /* mark semtable as 'no pointers', hiding from garbage collector */
+static union semtable semtable[SEMTABLESZ];
 
 static SemaRoot*
 semroot(uint32 *addr)
@@ -98,7 +100,7 @@ cansemacquire(uint32 *addr)
 void
 runtime·semacquire(uint32 volatile *addr)
 {
-\tSema s;\n+\tSema s;\t// Needs to be allocated on stack, otherwise garbage collector could deallocate it
 \tSemaRoot *root;
 
 \t// Easy case.

コアとなるコードの解説

1. union semtable の定義と #pragma dataflag 16:

   • 変更前は、semtable は匿名 union の配列として直接定義されていました。
   • 変更後、union semtable という名前付きの union が定義され、その後に semtable 配列が宣言されています。
   • 最も重要な変更は、static union semtable semtable[SEMTABLESZ]; の直前に挿入された #pragma dataflag 16 です。このディレクティブは、Goのコンパイラに対して、semtable 配列がポインタを含まないデータであることを明示的に伝えます。これにより、GCは semtable のメモリ領域をスキャンする際に、ポインタの有無を確認する処理をスキップし、誤ってポインタとして解釈したり、不適切に解放したりするリスクを排除します。これは、GCの効率性向上にも寄与します。

2. Sema s; のコメント追加:

   • runtime·semacquire 関数は、セマフォの取得（ロック）を行うランタイム関数です。
   • この関数内で宣言されているローカル変数 Sema s; の行に、// Needs to be allocated on stack, otherwise garbage collector could deallocate it というコメントが追加されました。
   • Sema 構造体は、セマフォの内部状態（例えば、待機中のゴルーチンリストへのポインタなど）を保持する可能性があります。もしこの s がヒープに割り当てられた場合、GCがそのポインタを追跡し、誤って解放してしまう可能性がありました。しかし、ローカル変数としてスタックに割り当てられることで、関数の実行が終了すると自動的に解放され、GCの介入なしに安全に管理されます。このコメントは、この設計意図とGCとの相互作用における重要性を強調しています。

これらの変更は、Goランタイムのメモリ管理とガベージコレクションの正確性を保証し、セマフォのような低レベルな同期プリミティブが安定して機能するために不可欠です。

関連リンク

• Go言語のガベージコレクションに関する公式ドキュメントやブログ記事 (コミット当時の情報にアクセスするのは難しいかもしれませんが、一般的な概念は共通です)
• Go言語のセマフォ実装に関するソースコード (src/runtime/sema.go や src/runtime/sema.goc の現在のバージョン)
• Go言語の go tool compile や go tool link のドキュメント（#pragma ディレクティブに関する情報が含まれる可能性があります）

参考にした情報源リンク

• Go言語の公式リポジトリ: https://github.com/golang/go
• Go言語のコードレビューシステム (Gerrit): https://golang.org/cl/6528043 (元の変更リスト)
• Go言語のガベージコレクションに関する一般的な情報源 (例: Goブログ、Goドキュメント)
• C言語の #pragma ディレクティブに関する一般的な情報源
• Go言語のランタイムに関する技術記事や解説 (特にメモリ管理やGCに焦点を当てたもの)