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

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

このコミットは、Go言語の標準ライブラリである encoding/gob パッケージにおけるデコード処理の簡素化を目的としています。特に、unsafe パッケージの使用に起因するポインタの「間接参照 (indirection)」追跡ロジックを削除し、コードの可読性と保守性を向上させています。この変更により、一部のベンチマークではわずかなパフォーマンス低下が見られますが、コード品質の改善が重視されています。

コミット

commit ce5bbfdde4ac3e2b8b1437e3ff12c69daec938a7
Author: Rob Pike <r@golang.org>
Date:   Mon Jun 30 15:47:11 2014 -0700

    encoding/gob: simplify allocation in decode.
    The old code's structure needed to track indirections because of the
    use of unsafe. That is no longer necessary, so we can remove all
    that tracking. The code cleans up considerably but is a little slower.
    We may be able to recover that performance drop. I believe the
    code quality improvement is worthwhile regardless.
    
    BenchmarkEndToEndPipe           5610          5780          +3.03%
    BenchmarkEndToEndByteBuffer     3156          3222          +2.09%
    
    LGTM=rsc
    R=rsc
    CC=golang-codereviews
    https://golang.org/cl/103700043

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

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

元コミット内容

encoding/gob: simplify allocation in decode.

古いコードの構造は、unsafe の使用により間接参照を追跡する必要がありました。これはもはや不要になったため、その追跡をすべて削除できます。コードはかなり整理されますが、少し遅くなります。そのパフォーマンス低下を回復できる可能性があります。コード品質の改善は、それにもかかわらず価値があると考えています。

BenchmarkEndToEndPipe 5610 5780 +3.03% BenchmarkEndToEndByteBuffer 3156 3222 +2.09%

変更の背景

このコミットの主な背景は、encoding/gob パッケージのデコード処理におけるコードの複雑性を軽減することです。以前の gob デコーダは、Goの unsafe パッケージを利用して、デコード対象のデータ構造内のポインタの間接参照（例えば、***int のようにポインタが複数層になっている場合）を明示的に追跡し、必要に応じてメモリを割り当てる必要がありました。

しかし、この unsafe の使用とそれに伴う間接参照の追跡は、コードを複雑にし、理解や保守を困難にしていました。コミットメッセージにあるように、「古いコードの構造は、unsafe の使用により間接参照を追跡する必要がありました。これはもはや不要になったため、その追跡をすべて削除できます。」という記述から、unsafe に依存しない、よりシンプルで安全なポインタの扱い方が可能になったことが示唆されます。

この変更は、コード品質の向上を最優先しており、たとえわずかなパフォーマンス低下があったとしても、その価値は十分にあると判断されています。ベンチマーク結果が示しているように、BenchmarkEndToEndPipe で3.03%の、BenchmarkEndToEndByteBuffer で2.09%のパフォーマンス低下が見られますが、これは許容範囲内とされています。将来的にはこのパフォーマンス低下を回復する可能性も示唆されています。

前提知識の解説

このコミットを理解するためには、以下のGo言語の概念とパッケージに関する知識が必要です。

1. encoding/gob パッケージ

encoding/gob は、Goのデータ構造をエンコード（シリアライズ）およびデコード（デシリアライズ）するためのGo固有のバイナリ形式を提供するパッケージです。異なるGoプログラム間でデータを交換したり、永続化したりする際に使用されます。gob は、データ型情報を自己記述的に含んでいるため、受信側は送信側の型定義を知らなくてもデータをデコードできます。

2. reflect パッケージ

reflect パッケージは、Goプログラムが実行時に自身の構造を検査し、操作するための機能を提供します。gob パッケージは、この reflect パッケージを extensively に利用して、任意のGoデータ構造をエンコード・デコードします。

  • reflect.Value: 任意のGoの値のランタイム表現です。これを通じて、値の型、種類 (Kind)、フィールド、メソッドなどにアクセスしたり、値を設定したりできます。
  • reflect.Type: 任意のGoの型のランタイム表現です。
  • reflect.Kind: 型の基本的なカテゴリ（例: reflect.Int, reflect.String, reflect.Struct, reflect.Ptr, reflect.Slice など）を表す列挙型です。
  • reflect.Ptr: ポインタ型を表す reflect.Kind の値です。
  • reflect.New(Type): 指定された型の新しいゼロ値を指すポインタを reflect.Value として返します。これは、新しいメモリを割り当てる際に使用されます。
  • reflect.Elem(): ポインタが指す要素の reflect.Value を返します。ポインタでない場合はパニックします。
  • reflect.Set(Value): reflect.Value に別の reflect.Value を設定します。

3. ポインタと間接参照 (Indirection)

Go言語では、ポインタはメモリ上のアドレスを指します。例えば、*int は整数へのポインタ、**int は整数へのポインタへのポインタです。gob のデコード処理では、エンコードされたデータを受信側のGoのデータ構造にマッピングする際に、これらのポインタを適切に解決し、必要に応じてメモリを割り当てる必要があります。

「間接参照」とは、ポインタを介して元の値にアクセスする階層の深さを指します。*int は1つの間接参照、**int は2つの間接参照を持ちます。

4. unsafe パッケージ (旧来の利用と今回の変更)

unsafe パッケージは、Goの型安全性とメモリ安全性の保証をバイパスする低レベルな操作を可能にします。これには、任意の型へのポインタを uintptr に変換したり、異なる型のポインタ間で変換したりする機能が含まれます。

以前の gob デコーダでは、unsafe を使用してポインタの間接参照を効率的に処理していました。しかし、unsafe の使用はコードを理解しにくく、バグを導入しやすいという欠点があります。このコミットでは、unsafe に依存しない reflect パッケージの機能（特に reflect.Value の操作）のみで間接参照の解決とメモリ割り当てを行うように変更されています。これにより、コードの安全性が向上し、理解が容易になります。

技術的詳細

このコミットの技術的な核心は、encoding/gob のデコード処理におけるポインタの間接参照の扱い方を根本的に変更した点にあります。

変更前の間接参照の扱い方

変更前は、decInstr (デコード命令) 構造体に indir というフィールドがあり、これはデコード対象のGoの型が持つポインタの間接参照の深さ（例: *int なら1、**int なら2）を追跡していました。

また、decIndirect というヘルパー関数が存在し、これは reflect.Value と indir の値を受け取り、指定された間接参照の深さまでポインタを辿り、途中で nil ポインタがあれば reflect.New を使って新しいメモリを割り当てていました。この decIndirect 関数は、unsafe パッケージの機能と組み合わせて使用され、低レベルなポインタ操作を行っていました。

各デコード関数（例: decBool, decInt8 など）は、decInstr の indir フィールドを参照し、decIndirect を呼び出して、最終的に値を設定する reflect.Value を取得していました。このアプローチは効率的である一方で、unsafe の使用と indir の明示的な追跡により、コードが複雑になり、エラーの温床となる可能性がありました。

変更後の間接参照の扱い方

このコミットでは、decInstr から indir フィールドが削除され、decIndirect 関数も完全に削除されました。代わりに、decAlloc という新しいヘルパー関数が導入されました。

decAlloc 関数は、reflect.Value を受け取り、その値がポインタである限り v.Elem() を呼び出してポインタを辿ります。途中で nil ポインタが見つかった場合、v.Set(reflect.New(v.Type().Elem())) を使って新しいメモリを割り当てます。このプロセスは、reflect.Value のメソッドのみを使用して行われるため、unsafe パッケージへの依存がなくなります。

これにより、各デコード関数は decAlloc(value) を呼び出すだけで、最終的に値を設定すべき reflect.Value を取得できるようになりました。例えば、decBool 関数は以前 i.decAlloc(value).SetBool(...) となっていましたが、変更後は decAlloc(value).SetBool(...) となり、decInstr の indir フィールドを参照する必要がなくなりました。

パフォーマンスへの影響

コミットメッセージに記載されているように、この変更は「少し遅くなる」とされています。これは、unsafe を使用した低レベルなポインタ操作が、reflect パッケージのより汎用的な操作に置き換えられたためと考えられます。reflect パッケージの操作は、型安全性を確保するために追加のチェックや間接的な処理を伴うことがあり、これがオーバーヘッドとなる可能性があります。

しかし、Rob Pikeは「コード品質の改善は、それにもかかわらず価値がある」と述べており、可読性と保守性の向上がパフォーマンスのわずかな低下を上回ると判断されています。

まとめ

このコミットは、encoding/gob のデコード処理において、unsafe パッケージへの依存を排除し、reflect パッケージの機能のみでポインタの間接参照とメモリ割り当てを管理するように変更しました。これにより、コードはより安全で理解しやすくなりましたが、わずかなパフォーマンスのトレードオフが発生しています。これは、Go言語の設計哲学である「シンプルさと安全性」を追求した結果と言えるでしょう。

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

このコミットにおける主要な変更は、src/pkg/encoding/gob/decode.go ファイルに集中しています。

  1. decInstr 構造体からの indir フィールドの削除:

    --- a/src/pkg/encoding/gob/decode.go
+++ b/src/pkg/encoding/gob/decode.go
@@ -131,7 +131,6 @@ type decInstr struct {
 	op    decOp
 	field int   // field number of the wire type
 	index []int // field access indices for destination type
-	indir int   // how many pointer indirections to reach the value in the struct
 	ovfl  error // error message for overflow/underflow (for arrays, of the elements)
 }

  2. decIndirect 関数の削除: decIndirect 関数全体が削除されています。

  3. decAlloc 関数の変更と導入: decAlloc 関数が decInstr のメソッドから独立した関数になり、indir の概念がなくなりました。

    --- a/src/pkg/encoding/gob/decode.go
+++ b/src/pkg/encoding/gob/decode.go
@@ -166,11 +146,17 @@ func ignoreTwoUints(i *decInstr, state *decoderState, v reflect.Value) {
  	state.decodeUint()
  }
  
+// Since the encoder writes no zeros, if we arrive at a decoder we have
+// a value to extract and store.  The field number has already been read
+// (it's how we knew to call this decoder).
+// Each decoder is responsible for handling any indirections associated
+// with the data structure.  If any pointer so reached is nil, allocation must
+// be done.
+
  // decAlloc takes a value and returns a settable value that can
-// be assigned to. If the value is a pointer (i.indir is positive),
-// decAlloc guarantees it points to storage.
-func (i *decInstr) decAlloc(v reflect.Value) reflect.Value {
-	if i.indir > 0 {
+// be assigned to. If the value is a pointer, decAlloc guarantees it points to storage.
+func decAlloc(v reflect.Value) reflect.Value {
+	for v.Kind() == reflect.Ptr {
  	if v.IsNil() {
  		v.Set(reflect.New(v.Type().Elem()))
  	}

  4. 各デコード関数における decAlloc の呼び出し方の変更: i.decAlloc(value) が decAlloc(value) に変更されています。 例: decBool

    --- a/src/pkg/encoding/gob/decode.go
+++ b/src/pkg/encoding/gob/decode.go
@@ -181,7 +167,7 @@ func (i *decInstr) decAlloc(v reflect.Value) reflect.Value {
  
  // decBool decodes a uint and stores it as a boolean in value.\n func decBool(i *decInstr, state *decoderState, value reflect.Value) {
-	i.decAlloc(value).SetBool(state.decodeUint() != 0)
+	decAlloc(value).SetBool(state.decodeUint() != 0)
  }

    他の decInt8, decUint8, decInt16, decUint16, decInt32, decUint32, decInt64, decUint64, decFloat32, decFloat64, decComplex64, decComplex128, decUint8Slice, decString など、すべてのプリミティブ型およびスライス・文字列のデコード関数で同様の変更が行われています。

  5. decodeArrayHelper, decodeArray, decodeMap, decodeSlice, decodeInterface 関数のシグネチャとロジックの変更: これらの関数から indir や elemIndir, keyIndir といった間接参照に関する引数が削除され、内部のロジックも簡素化されています。 例: decodeArrayHelper

    --- a/src/pkg/encoding/gob/decode.go
+++ b/src/pkg/encoding/gob/decode.go
@@ -499,14 +439,10 @@ func (dec *Decoder) ignoreSingle(engine *decEngine) {
  }
  
  // decodeArrayHelper does the work for decoding arrays and slices.\n-func (dec *Decoder) decodeArrayHelper(state *decoderState, value reflect.Value, elemOp decOp, length, elemIndir int, ovfl error) {
-	instr := &decInstr{elemOp, 0, nil, elemIndir, ovfl}
+func (dec *Decoder) decodeArrayHelper(state *decoderState, value reflect.Value, elemOp decOp, length int, ovfl error) {
+	instr := &decInstr{elemOp, 0, nil, ovfl}
  	for i := 0; i < length; i++ {
  		if state.b.Len() == 0 {
  			errorf("decoding array or slice: length exceeds input size (%d elements)", length)
  		}
-		elem := value.Index(i)
-		if elemIndir > 1 {
-			elem = decIndirect(elem, elemIndir)
-		}
-		elemOp(instr, state, elem)
+		elemOp(instr, state, value.Index(i))
  	}
  }

  6. decOpFor および gobDecodeOpFor 関数のシグネチャ変更: これらの関数も、間接参照の深さを返す int 型の戻り値が削除されています。

コアとなるコードの解説

このコミットの核心は、encoding/gob のデコード処理から「間接参照の追跡」という概念を排除し、よりシンプルで unsafe に依存しないメモリ割り当てメカニズムに移行した点にあります。

decInstr から indir の削除

以前の decInstr 構造体には indir フィールドがあり、これはデコード対象のGoの型が持つポインタの間接参照の深さを示していました。例えば、int なら0、*int なら1、**int なら2といった具合です。この indir の値に基づいて、デコーダは decIndirect 関数を呼び出し、適切な深さまでポインタを辿ってメモリを割り当てていました。

indir フィールドが削除されたことで、decInstr はよりシンプルになり、デコード命令自体が間接参照の深さを意識する必要がなくなりました。

decIndirect 関数の削除と decAlloc の変更

decIndirect 関数は、unsafe パッケージと連携して、ポインタの階層を辿り、途中で nil ポインタがあれば新しいメモリを割り当てる役割を担っていました。この関数が削除されたことは、unsafe への依存がなくなったことを意味します。

代わりに、decAlloc 関数が大幅に変更され、独立した関数として定義されました。

func decAlloc(v reflect.Value) reflect.Value {
	for v.Kind() == reflect.Ptr {
		if v.IsNil() {
			v.Set(reflect.New(v.Type().Elem()))
		}
		v = v.Elem()
	}
	return v
}

この新しい decAlloc 関数は、reflect.Value を引数に取り、その値がポインタである限りループを回します。

  • v.Kind() == reflect.Ptr: 現在の reflect.Value がポインタ型であるかを確認します。
  • v.IsNil(): ポインタが nil であるかを確認します。
  • v.Set(reflect.New(v.Type().Elem())): もしポインタが nil であれば、reflect.New を使ってポインタが指す型の新しいゼロ値を割り当て、そのポインタを設定します。reflect.New は常にポインタを返すため、v.Set で直接設定できます。
  • v = v.Elem(): ポインタが指す要素の reflect.Value を取得し、次のループでその要素を処理します。

このループは、ポインタの階層を一番奥の非ポインタ型に到達するまで、または nil でないポインタに到達するまで辿り、必要に応じてメモリを割り当てます。最終的に、decAlloc は、値を直接設定できる reflect.Value（つまり、ポインタではない、またはポインタの最終的な参照先）を返します。

各デコード関数での利用

この変更により、各デコード関数（例: decBool, decInt8 など）は、値を設定する前に decAlloc(value) を呼び出すだけでよくなりました。 例えば、decBool の変更前と変更後を比較すると、その簡素化が明らかです。

変更前:

func decBool(i *decInstr, state *decoderState, value reflect.Value) {
	i.decAlloc(value).SetBool(state.decodeUint() != 0)
}

ここでは i.decAlloc(value) と、decInstr のメソッドとして decAlloc が呼び出され、decInstr の indir フィールドが考慮されていました。

変更後:

func decBool(i *decInstr, state *decoderState, value reflect.Value) {
	decAlloc(value).SetBool(state.decodeUint() != 0)
}

変更後は、decAlloc(value) と独立した関数として呼び出され、decInstr の indir フィールドは不要になりました。これにより、デコードロジックから間接参照の複雑な管理が切り離され、各デコード関数はより単一責任の原則に則った形になりました。

複合型（配列、マップ、スライス、インターフェース）のデコード

decodeArrayHelper, decodeArray, decodeMap, decodeSlice, decodeInterface といった複合型をデコードする関数も、indir や elemIndir, keyIndir といった間接参照に関する引数が削除され、内部のロジックが decAlloc を利用するように簡素化されました。これにより、これらの関数も間接参照の深さを明示的に管理する必要がなくなり、コードがよりクリーンになりました。

例えば、decodeArrayHelper の変更では、elemIndir 引数が削除され、decIndirect の呼び出しもなくなっています。代わりに、value.Index(i) で直接要素の reflect.Value を取得し、その要素に対して elemOp を適用しています。これは、elemOp の内部で decAlloc が呼び出されるため、間接参照の解決とメモリ割り当てが適切に行われることを前提としています。

まとめ

このコミットは、encoding/gob のデコード処理におけるポインタの間接参照の管理を、unsafe パッケージと indir フィールドに依存する複雑なメカニズムから、reflect パッケージの機能のみを使用するシンプルで安全な decAlloc 関数に集約しました。これにより、コードの可読性、保守性、安全性が大幅に向上しました。パフォーマンスのわずかな低下はありますが、コード品質の改善という点で大きなメリットがある変更と言えます。

関連リンク

参考にした情報源リンク