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

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

このコミットは、GoランタイムのC言語で書かれたソースコードにおいて、関数の属性を定義するために使用されていた#pragma textflagディレクティブの数値表現を、より意味のあるシンボル表現（例: NOSPLIT）に置き換える変更です。これにより、コードの可読性と保守性が向上し、各関数の意図する動作がより明確になります。特に、スタックの分割挙動に関する指定が明確化されています。

コミット

  • コミットハッシュ: e838334beb38c20d2b4035b53ec4e3e3487844f9
  • Author: Keith Randall khr@golang.org
  • Date: Mon Aug 12 13:47:18 2013 -0700

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

https://github.com/golang/go/commit/e838334beb38c20d2b4035b53ec4e3e3487844f9

元コミット内容

runtime: change textflags from numbers to symbols

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12798043

変更の背景

Go言語のランタイムは、パフォーマンスと低レベルな制御のためにC言語（実際にはGoのツールチェインで処理されるCのような言語、gocファイルなど）で書かれた部分を多く含んでいます。これらのファイルでは、コンパイラやリンカに対して特定の関数の挙動を指示するために#pragma textflagというディレクティブが使用されていました。

以前は、このディレクティブに数値が直接指定されていました（例: #pragma textflag 7）。しかし、数値だけではその数値が具体的にどのような意味を持つのか、コードを読むだけでは直感的に理解できませんでした。特に、Goランタイムの重要な機能である「スタックの自動拡張（stack splitting）」に関連するフラグは、その挙動がパフォーマンスや安全性に直結するため、非常に重要です。

このコミットの背景には、以下の目的があったと考えられます。

  1. 可読性の向上: 数値の代わりにNOSPLITのようなシンボリックな名前を使用することで、開発者がコードを読んだ際に、その関数がスタック分割を行わないことが一目で理解できるようになります。
  2. 保守性の向上: 数値の意味を記憶したり、ドキュメントを参照したりする手間が省け、将来的な変更やデバッグが容易になります。
  3. 意図の明確化: 特定の関数がなぜスタック分割をしないのか、その設計意図がコード自体に埋め込まれる形になります。

前提知識の解説

GoランタイムとC言語（gocファイル）

Go言語のランタイムは、ガベージコレクション、スケジューラ、チャネル、インターフェースなど、Goプログラムの実行を支える低レベルな機能を提供します。これらの機能の一部は、Go言語自体ではなく、C言語に似た構文を持つファイル（.cや.goc拡張子を持つファイル）で実装されています。これらのファイルは、Goのツールチェインによってコンパパイルされ、最終的なバイナリに組み込まれます。

#pragma textflag

#pragmaディレクティブは、コンパイラに対して特別な指示を与えるためのものです。Goのツールチェインにおける#pragma textflagは、特定の関数（または「テキスト」セクション）に対して、リンカやランタイムがどのように扱うべきかを指示するフラグを設定するために使用されます。

Goのスタック自動拡張（Stack Splitting）

Go言語の大きな特徴の一つに、goroutineのスタックが自動的に拡張・縮小される「スタック自動拡張（Stack Splitting）」があります。これにより、goroutineは非常に小さなスタックサイズで開始でき、必要に応じて自動的にスタック領域を確保するため、メモリ効率が良く、数百万ものgoroutineを同時に実行することが可能になります。

スタック自動拡張は、関数呼び出しの際に、呼び出される関数のプロローグで現在のスタックサイズが十分であるかチェックし、不足していれば新しい、より大きなスタックセグメントに切り替えることで実現されます。

NOSPLITフラグ

NOSPLITは、特定の関数がスタック自動拡張のチェックを行わないことを示すフラグです。つまり、このフラグが設定された関数は、スタックが不足していても自動的に拡張されません。

NOSPLITが使用される主な理由は以下の通りです。

  • 低レベルなランタイム関数: スタック自動拡張のメカニズム自体を実装しているような、非常に低レベルなランタイム関数では、スタックチェックを行うと循環参照になったり、オーバーヘッドが大きくなったりする可能性があります。
  • アセンブリ言語で書かれた関数: アセンブリ言語で書かれた関数は、スタックの管理をプログラマが直接行うため、自動拡張のメカニズムと競合する可能性があります。
  • 非常に短い関数: 非常に短い関数でスタックチェックのオーバーヘッドを避けたい場合。
  • スタックを分割できない状況: シグナルハンドラなど、スタックを安全に分割できないコンテキストで実行される関数。

以前の数値フラグでは、7がNOSPLITに相当していました。この数値は、複数のビットフラグの組み合わせを表しており、そのうちの一つがスタック分割を無効にするフラグでした。

技術的詳細

このコミットの核心は、#pragma textflagディレクティブで使用される数値リテラルを、../../cmd/ld/textflag.hで定義されたシンボリック定数に置き換えることです。

具体的には、多くのファイルで#pragma textflag 7という記述が#pragma textflag NOSPLITに変更されています。

textflag.hファイルは、Goのリンカ（cmd/ld）が使用するテキストフラグの定義を含んでいます。このファイルには、以下のような定義が含まれていると推測されます（コミット時点の正確な内容は確認が必要ですが、一般的なGoのリンカの挙動から推測）。

// textflag.h (概念的な内容)
#define NOSPLIT 1 // スタック分割を行わない
// 他のフラグ定義...

ここで、NOSPLITはビットフラグの一つであり、数値の7は、例えばNOSPLIT | OTHER_FLAG_A | OTHER_FLAG_Bのような複数のフラグの組み合わせを表していた可能性があります。このコミットでは、その組み合わせの中からNOSPLITという最も重要な意味を持つフラグを明示的に指定することで、コードの意図を明確にしています。

この変更は、Goのビルドシステムとリンカが、数値フラグとシンボリックフラグの両方を認識するように進化していることを示唆しています。シンボリックフラグへの移行は、Goの内部開発におけるコード品質と保守性への継続的な取り組みの一環です。

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

このコミットは、Goランタイムの非常に多くのC言語ソースファイルにわたる変更です。ここでは、src/pkg/runtime/alg.cにおける変更を例として示します。

--- a/src/pkg/runtime/alg.c
+++ b/src/pkg/runtime/alg.c
@@ -4,6 +4,7 @@
 
  #include "runtime.h"
  #include "type.h"
 +#include "../../cmd/ld/textflag.h"
 
  #define M0 (sizeof(uintptr)==4 ? 2860486313UL : 33054211828000289ULL)
  #define M1 (sizeof(uintptr)==4 ? 3267000013UL : 23344194077549503ULL)
@@ -499,7 +500,7 @@ runtime·hashinit(void)\n  }\n \n  // func equal(t *Type, x T, y T) (ret bool)\n-#pragma textflag 7\n+#pragma textflag NOSPLIT\n  void\n  runtime·equal(Type *t, ...)\n  {\n```

この変更は、`src/pkg/runtime`ディレクトリ以下の多数のファイル（`atomic_386.c`, `atomic_amd64.c`, `atomic_arm.c`, `chan.c`, `hashmap.c`, `iface.c`, `panic.c`, `proc.c`, `race.c`, `slice.c`など、コミットログに記載されている36ファイル）に適用されています。

各ファイルで共通しているのは、以下の2点です。

1.  `#include "../../cmd/ld/textflag.h"`の追加: `NOSPLIT`などのシンボリック定数を参照するために、リンカのテキストフラグ定義ファイルがインクルードされています。
2.  `#pragma textflag 7`が`#pragma textflag NOSPLIT`に置き換えられている: これがこのコミットの主要な変更点です。

## コアとなるコードの解説

上記の`src/pkg/runtime/alg.c`の変更箇所を例に解説します。

```c
 #include "runtime.h"
 #include "type.h"
+#include "../../cmd/ld/textflag.h" // 新しく追加された行

この行は、NOSPLITというシンボルが定義されているヘッダーファイルtextflag.hをインクルードしています。このファイルは、Goのリンカ（cmd/ld）が使用する内部的な定義を含んでおり、NOSPLITのようなテキストフラグのシンボリックな値をGoのランタイムコードで利用できるようにします。

 // func equal(t *Type, x T, y T) (ret bool)
-#pragma textflag 7 // 変更前
+#pragma textflag NOSPLIT // 変更後
 void
 runtime·equal(Type *t, ...)
 {

この部分がこのコミットの核心的な変更です。

  • 変更前は#pragma textflag 7と記述されていました。数値の7は、Goのリンカにとって特定の意味を持つビットフラグの組み合わせでした。この場合、7は「スタック分割を行わない（NOSPLIT）」という指示を含んでいました。しかし、この数値を見ただけでは、その意図を理解するのは困難でした。
  • 変更後は#pragma textflag NOSPLITと記述されています。NOSPLITは、この関数（runtime·equal）がGoランタイムのスタック自動拡張の対象外であることを明示的に示します。つまり、この関数が呼び出されても、Goランタイムはスタックのサイズチェックや拡張を行いません。

runtime·equal関数は、Goの型システムにおいて2つの値が等しいかどうかを比較する、非常に基本的なランタイム関数です。このような低レベルで頻繁に呼び出される関数では、スタック分割のオーバーヘッドを避けるためにNOSPLITが指定されるのが一般的です。

この変更により、runtime·equal関数がスタック分割を行わないという意図が、コードを読むだけで明確に理解できるようになりました。これは、Goランタイムのコードベース全体の可読性と保守性を大幅に向上させるものです。

関連リンク

  • Go言語のスタック自動拡張に関する議論 (古いもの): https://groups.google.com/g/golang-nuts/c/yL412111111/m/yL412111111 (これは一般的な情報源であり、特定のコミットに関連するものではありませんが、スタック分割の背景を理解するのに役立ちます)
  • Goのリンカのドキュメント（cmd/ld）: Goのソースコードリポジトリ内のcmd/ld/doc.goや関連ドキュメントが、textflagの詳細な意味を説明している場合があります。

参考にした情報源リンク

  • Go言語のソースコード (特にsrc/cmd/ld/textflag.hやsrc/pkg/runtime以下のC言語ファイル)
  • Go言語の公式ドキュメント
  • Go言語のコミット履歴とコードレビューコメント
  • Go言語のスタック自動拡張に関する一般的な技術記事