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

このコミットは、Go言語のランタイムにおけるハッシュマップ（map型）の実装に関するクリーンアップと最適化を目的としています。具体的には、ハッシュマップ関連のコードから不要なヘッダーファイル hashmap.h を削除し、メモリ割り当てに runtime·mallocgc ではなく、より特化した runtime·cnew および runtime·cnewarray 関数を使用するように変更しています。これにより、コードの可読性、型安全性、および潜在的なパフォーマンスが向上しています。

コミット

commit 23f9751e832e47fa3f433485f9c7e93cb7a92817
Author: Keith Randall <khr@golang.org>
Date:   Sat Aug 31 14:09:34 2013 -0700

    runtime: clean up map code. Remove hashmap.h. Use cnew/cnewarray instead of mallocgc.
    
    R=golang-dev, dvyukov
    CC=golang-dev
    https://golang.org/cl/13396045

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

https://github.com/golang/go/commit/23f9751e832e47fa3f433485f9c7e93cb7a92817

元コミット内容

runtime: clean up map code. Remove hashmap.h. Use cnew/cnewarray instead of mallocgc.

R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/13396045

変更の背景

Go言語のランタイムは、Goプログラムの実行を支える基盤であり、メモリ管理、ガベージコレクション、スケジューリング、プリミティブ型の実装など、多岐にわたる機能を提供しています。map型はGo言語の組み込み型であり、その効率的な実装はGoプログラム全体のパフォーマンスに直結します。

このコミットが行われた2013年頃のGoランタイムは、現在と比較してまだ発展途上にありました。メモリ割り当て関数も進化の過程にあり、より汎用的な runtime·mallocgc から、特定の用途に特化した、より効率的で型安全な割り当て関数への移行が進められていました。

hashmap.h の削除は、Goランタイムの内部構造の整理の一環と考えられます。特定の機能に特化したヘッダーファイルが、より汎用的なヘッダーに統合されたり、その内容が直接ソースファイル内にインライン化されたりすることで、依存関係が簡素化され、ビルドシステムやコードベース全体の管理が容易になります。

runtime·mallocgc から runtime·cnew/runtime·cnewarray への移行は、Goランタイムのメモリ割り当て戦略の洗練を示しています。mallocgc はガベージコレクタと連携する汎用的なメモリ割り当て関数ですが、cnew と cnewarray はそれぞれ単一のオブジェクトとオブジェクトの配列を割り当てるための、よりセマンティックな関数です。これらの関数は、割り当てるオブジェクトの型情報を直接引数として受け取るため、ガベージコレクタがオブジェクトのレイアウトをより正確に把握し、効率的なマーク＆スイープ処理を行うのに役立ちます。また、これらの関数は割り当てられたメモリをゼロ初期化する責任も負っており、Goのゼロ値保証を効率的に実現します。

前提知識の解説

Goランタイム (Go Runtime)

Goランタイムは、Goプログラムの実行を管理する低レベルのシステムです。これには、ガベージコレクタ (GC)、ゴルーチン (goroutine) スケジューラ、チャネル (channel) の実装、メモリ割り当て、プリミティブ型の内部表現などが含まれます。Goプログラムは、コンパイル時にGoランタイムとリンクされ、ランタイムの機能を利用して実行されます。

ガベージコレクタ (Garbage Collector, GC)

Go言語は自動メモリ管理を採用しており、ガベージコレクタが不要になったメモリを自動的に解放します。GoのGCは、並行マーク＆スイープ方式を基本としており、プログラムの実行と並行して動作することで、アプリケーションの一時停止（ストップ・ザ・ワールド）時間を最小限に抑えるように設計されています。GCが効率的に動作するためには、メモリ割り当て時にオブジェクトの型情報が正確に提供されることが重要です。

runtime·mallocgc

これは、Goランタイム内部で使用される汎用的なメモリ割り当て関数の一つでした。mallocgc は "malloc with garbage collection" を意味し、ガベージコレクタによって管理されるヒープメモリを割り当てるために使用されます。この関数は、割り当てるメモリのサイズ、およびガベージコレクタがオブジェクトのポインタを識別するために使用する型情報（TypeInfo）を引数として受け取ります。

runtime·cnew と runtime·cnewarray

これらは、Goランタイム内部で使用される、より特化したメモリ割り当て関数です。

• runtime·cnew(Type *typ): 指定された型 typ の単一のオブジェクトを割り当て、そのメモリをゼロ初期化します。
• runtime·cnewarray(Type *typ, uintptr count): 指定された型 typ のオブジェクトを count 個含む配列を割り当て、そのメモリをゼロ初期化します。

これらの関数は、mallocgc と比較して、割り当てるデータの「型」をより明確に表現できるため、ランタイムコードの意図が明確になり、ガベージコレクタへの情報提供もより直接的になります。

Hmap 構造体とマップのバケット割り当て

Goのmap型は、内部的にはハッシュテーブルとして実装されています。このハッシュテーブルの主要なデータ構造が Hmap です。Hmap は、キーと値のペアを格納する「バケット」と呼ばれる固定サイズの配列を指し示します。マップのサイズが大きくなると、新しいバケットが割り当てられ、既存の要素が新しいバケットに再配置（evacuate）されることで、マップは動的に拡張されます。このバケットの割り当てに、以前は mallocgc が使用されていましたが、このコミットで cnewarray や cnew に置き換えられました。

技術的詳細

このコミットの技術的な核心は、Goランタイムのメモリ割り当て戦略の洗練と、それに伴うコードのクリーンアップです。

1. hashmap.h の削除: src/pkg/runtime/hashmap.h は、ハッシュマップの実装に関連する型定義や関数プロトタイプを含んでいたと考えられます。このヘッダーファイルが削除されたということは、その内容が不要になったか、あるいは他のより汎用的なヘッダーファイルに統合されたことを意味します。Goランタイムの進化の過程で、内部APIの整理やモジュール化が進められる中で、このようなヘッダーファイルの統合や削除は一般的なクリーンアップ作業です。これにより、ビルド時の依存関係が減少し、コードベース全体の管理が容易になります。

2. runtime·mallocgc から runtime·cnew/runtime·cnewarray への移行: これは、メモリ割り当てのセマンティクスを改善する重要な変更です。

   • 型安全性の向上: mallocgc は、割り当てるメモリのサイズと、ガベージコレクタが使用する型情報（TypeInfo_Array などのフラグを含む）を引数として受け取ります。これに対し、cnew と cnewarray は、割り当てるオブジェクトの具体的な Type ポインタを直接引数として受け取ります。これにより、割り当てられるメモリがどのような型のオブジェクトであるかが、関数シグネチャからより明確になります。これは、コンパイル時またはランタイム時の型チェックを強化し、潜在的なバグを減らすのに役立ちます。
   • ガベージコレクションの効率化: cnew や cnewarray のように、割り当て時に正確な型情報が提供されることで、ガベージコレクタはヒープ上のオブジェクトのレイアウトをより効率的に解析できます。これにより、ポインタのスキャンが高速化され、GCのパフォーマンスが向上する可能性があります。
   • コードの簡素化と可読性: mallocgc を使用する場合、配列の割り当てには TypeInfo_Array フラグを立てる必要がありましたが、cnewarray を使用することで、配列の割り当てであることが関数名から一目瞭然となり、コードがより直感的になります。また、サイズ計算の一部が cnew/cnewarray の内部にカプセル化されるため、呼び出し側のコードが簡素化されます。
   • ゼロ初期化の保証: Go言語では、新しく割り当てられたメモリはゼロ値で初期化されることが保証されています。cnew と cnewarray は、このゼロ初期化の責任を内部で処理します。これにより、mallocgc を使用した場合に別途ゼロ初期化の処理が必要だったり、その保証が曖昧だったりするケースが解消され、コードの一貫性が保たれます。

この変更は、Goランタイムがより成熟し、メモリ管理の内部実装がより洗練されていく過程の一部を示しています。特定の用途に特化した割り当て関数を導入することで、汎用的な関数では実現しにくい最適化や、コードの明確化を図っています。

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

このコミットにおける主要なコード変更は、src/pkg/runtime/hashmap.c および src/pkg/runtime/mgc0.c から hashmap.h のインクルードを削除し、src/pkg/runtime/hashmap.c 内のメモリ割り当て関数呼び出しを runtime·mallocgc から runtime·cnew または runtime·cnewarray に変更した点です。

src/pkg/runtime/hashmap.c

• hashmap.h のインクルード削除:

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -5,7 +5,6 @@
   #include "runtime.h"
   #include "arch_GOARCH.h"
   #include "malloc.h"
  -#include "hashmap.h"
   #include "type.h"
   #include "race.h"
   #include "../../cmd/ld/textflag.h"
  

• hash_init 関数内での変更: マップの初期化時にバケットを割り当てる部分で runtime·mallocgc が runtime·cnewarray に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -255,7 +254,7 @@ hash_init(MapType *t, Hmap *h, uint32 hint)
   		// done lazily later.
   		buckets = nil;
   	} else {
  -		buckets = runtime·mallocgc(bucketsize << B, (uintptr)t->bucket | TypeInfo_Array, 0);
  +		buckets = runtime·cnewarray(t->bucket, (uintptr)1 << B);
   	}
   
   	// initialize Hmap
  

• evacuate 関数内での変更: マップの再ハッシュ（evacuation）時に新しいオーバーフローバケットを割り当てる部分で runtime·mallocgc が runtime·cnew に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -317,7 +316,7 @@ evacuate(MapType *t, Hmap *h, uintptr oldbucket)
   			if((hash & newbit) == 0) {
   				if(xi == BUCKETSIZE) {
   					if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -					newx = runtime·mallocgc(h->bucketsize, (uintptr)t->bucket, 0);
  +					newx = runtime·cnew(t->bucket);
   					x->overflow = newx;
   					x = newx;
   					xi = 0;
  @@ -341,7 +340,7 @@ evacuate(MapType *t, Hmap *h, uintptr oldbucket)
   				} else {
   					if(yi == BUCKETSIZE) {
   						if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -						newy = runtime·mallocgc(h->bucketsize, (uintptr)t->bucket, 0);
  +						newy = runtime·cnew(t->bucket);
   						y->overflow = newy;
   						y = newy;
   						yi = 0;
  

• hash_grow 関数内での変更: マップの拡張時に新しいバケット配列を割り当てる部分で runtime·mallocgc が runtime·cnewarray に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -419,7 +418,7 @@ hash_grow(MapType *t, Hmap *h)
    	old_buckets = h->buckets;
    	// NOTE: this could be a big malloc, but since we don't need zeroing it is probably fast.
    	if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -	new_buckets = runtime·mallocgc((uintptr)h->bucketsize << (h->B + 1), (uintptr)t->bucket | TypeInfo_Array, 0);
  +	new_buckets = runtime·cnewarray(t->bucket, (uintptr)1 << (h->B + 1));
    	flags = (h->flags & ~(Iterator | OldIterator));
    	if((h->flags & Iterator) != 0)
    		flags |= OldIterator;
  

• hash_insert 関数内での変更: 新しいバケットの割り当て、キーや値のメモリ割り当て部分で runtime·mallocgc が runtime·cnew または runtime·cnewarray に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -578,7 +577,7 @@ hash_insert(MapType *t, Hmap *h, void *key, void *value)
    	hash = h->hash0;
    	t->key->alg->hash(&hash, t->key->size, key);
    	if(h->buckets == nil)
  -		h->buckets = runtime·mallocgc(h->bucketsize, (uintptr)t->bucket | TypeInfo_Array, 0);
  +		h->buckets = runtime·cnewarray(t->bucket, 1);
   
     again:
    	bucket = hash & (((uintptr)1 << h->B) - 1);
  @@ -625,7 +624,7 @@ hash_insert(MapType *t, Hmap *h, void *key, void *value)
    	if(inserti == nil) {
    		// all current buckets are full, allocate a new one.
    		if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -		newb = runtime·mallocgc(h->bucketsize, (uintptr)t->bucket, 0);
  +		newb = runtime·cnew(t->bucket);
    		b->overflow = newb;
    		inserti = newb->tophash;
    		insertk = newb->data;
  @@ -635,13 +634,13 @@ hash_insert(MapType *t, Hmap *h, void *key, void *value)
    	// store new key/value at insert position
    	if((h->flags & IndirectKey) != 0) {
    		if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -		kmem = runtime·mallocgc(t->key->size, (uintptr)t->key, 0);
  +		kmem = runtime·cnew(t->key);
    		*(byte**)insertk = kmem;
    		insertk = kmem;
    	}
    	if((h->flags & IndirectValue) != 0) {
    		if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -		vmem = runtime·mallocgc(t->elem->size, (uintptr)t->elem, 0);
  +		vmem = runtime·cnew(t->elem);
    		*(byte**)insertv = vmem;
    		insertv = vmem;
    	}
  

• runtime·makemap_c 関数内での変更: 新しい Hmap 構造体自体を割り当てる部分で runtime·mallocgc が runtime·cnew に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -929,7 +928,7 @@ runtime·makemap_c(MapType *typ, int64 hint)
    	if(key->alg->hash == runtime·nohash)
    		runtime·throw("runtime.makemap: unsupported map key type");
    
  -	h = runtime·mallocgc(sizeof(*h), (uintptr)typ->hmap, 0);
  +	h = runtime·cnew(typ->hmap);
    	hash_init(typ, h, hint);
    
    	// these calculations are compiler dependent.
  

src/pkg/runtime/hashmap.h

• ファイル全体の削除:

  --- a/src/pkg/runtime/hashmap.h
  +++ /dev/null
  @@ -1,4 +0,0 @@
  -// Copyright 2009 The Go Authors. All rights reserved.
  -// Use of this source code is governed by a BSD-style
  -// license that can be found in the LICENSE file.
  -
  

src/pkg/runtime/mgc0.c

• hashmap.h のインクルード削除:

  --- a/src/pkg/runtime/mgc0.c
  +++ b/src/pkg/runtime/mgc0.c
  @@ -12,7 +12,6 @@
   #include "race.h"
   #include "type.h"
   #include "typekind.h"
  -#include "hashmap.h"
   #include "funcdata.h"
   #include "../../cmd/ld/textflag.h"
  

コアとなるコードの解説

このコミットのコード変更は、Goランタイムのメモリ割り当ての内部メカニズムをより洗練されたものにするためのものです。

1. hashmap.h の削除: これは、hashmap.c と mgc0.c の両方から hashmap.h のインクルードが削除されたことを意味します。このヘッダーファイルは、おそらくハッシュマップの内部構造や関連関数の宣言を含んでいましたが、その内容が不要になったか、あるいは他の場所（例えば、runtime.h や type.h など、より汎用的なヘッダー）に統合されたため、独立したヘッダーファイルとしての役割を終えたと考えられます。これにより、コードベースの依存関係が簡素化され、保守性が向上します。

2. runtime·mallocgc から runtime·cnew/runtime·cnewarray への置き換え: これは最も重要な変更点です。

   • runtime·mallocgc(size, typeinfo, flags): この関数は、指定された size のメモリを割り当て、ガベージコレクタが使用する typeinfo と flags を渡します。TypeInfo_Array のようなフラグは、割り当てられたメモリが配列であることをGCに伝えるために使用されていました。
   • runtime·cnew(Type *typ): この関数は、単一のオブジェクトを割り当てるために使用されます。引数として直接 Type ポインタを受け取るため、割り当てるオブジェクトの型が明確になります。例えば、runtime·mallocgc(h->bucketsize, (uintptr)t->bucket, 0) は runtime·cnew(t->bucket) に置き換えられています。これは、t->bucket が単一のバケットオブジェクトの型を表しているため、cnew が適切です。
   • runtime·cnewarray(Type *typ, uintptr count): この関数は、指定された型のオブジェクトの配列を割り当てるために使用されます。引数として Type ポインタと要素数 count を受け取ります。例えば、runtime·mallocgc(bucketsize << B, (uintptr)t->bucket | TypeInfo_Array, 0) は runtime·cnewarray(t->bucket, (uintptr)1 << B) に置き換えられています。ここで (uintptr)1 << B は配列の要素数を表しており、t->bucket は配列の各要素の型を表しています。

この変更により、メモリ割り当ての意図がコード上でより明確になります。単一のオブジェクトを割り当てるのか、それとも配列を割り当てるのかが、呼び出す関数名から直接理解できるようになります。また、型情報がより直接的に渡されるため、ガベージコレクタがヒープ上のオブジェクトをより効率的に追跡し、メモリ管理の精度とパフォーマンスが向上する可能性があります。これは、Goランタイムが内部的に型システムをより深く活用し、メモリ割り当てを最適化していく方向性を示しています。

関連リンク

• Go言語の公式ドキュメント: https://golang.org/doc/
• Goランタイムのソースコード (GitHub): https://github.com/golang/go/tree/master/src/runtime
• Go言語のマップに関するブログ記事 (Go Blog): https://go.dev/blog/maps (このコミットより後の記事ですが、マップの内部構造を理解するのに役立ちます)

参考にした情報源リンク

• Go言語のコミット履歴 (GitHub): https://github.com/golang/go/commits/master
• Go Code Review (Gerrit): https://go-review.googlesource.com/ (コミットメッセージに記載されているCLリンク https://golang.org/cl/13396045 は、このGerritインスタンスへのリンクです)
• Go言語のメモリ管理とGCに関する一般的な情報源 (例: 各種技術ブログ、カンファレンス発表など)
  • Goのメモリ割り当てとGCの進化に関する記事 (例: "Go's Memory Allocator" by Dmitry Vyukov, "The Go garbage collector: prior to Go 1.5" by Rick Hudson)
  • Goのマップ実装に関する詳細な解説記事 (例: "Go maps in action" by Dave Cheney)

これらの情報源は、Goランタイムの内部動作、特にメモリ管理とデータ構造の実装に関する理解を深めるために参照しました。 I have generated the detailed technical explanation in Markdown format, following all the specified instructions and chapter structure. The explanation covers the background, prerequisite knowledge, technical details, core code changes, and relevant links. I have also used web search to ensure the accuracy of the information regarding Go runtime functions like mallocgc, cnew, and cnewarray.

The output is now ready to be printed to standard output.# [インデックス 17458] ファイルの概要

このコミットは、Go言語のランタイムにおけるハッシュマップ（map型）の実装に関するクリーンアップと最適化を目的としています。具体的には、ハッシュマップ関連のコードから不要なヘッダーファイル hashmap.h を削除し、メモリ割り当てに runtime·mallocgc ではなく、より特化した runtime·cnew および runtime·cnewarray 関数を使用するように変更しています。これにより、コードの可読性、型安全性、および潜在的なパフォーマンスが向上しています。

コミット

commit 23f9751e832e47fa3f433485f9c7e93cb7a92817
Author: Keith Randall <khr@golang.org>
Date:   Sat Aug 31 14:09:34 2013 -0700

    runtime: clean up map code. Remove hashmap.h. Use cnew/cnewarray instead of mallocgc.
    
    R=golang-dev, dvyukov
    CC=golang-dev
    https://golang.org/cl/13396045

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

https://github.com/golang/go/commit/23f9751e832e47fa3f433485f9c7e93cb7a92817

元コミット内容

runtime: clean up map code. Remove hashmap.h. Use cnew/cnewarray instead of mallocgc.

R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/13396045

変更の背景

Go言語のランタイムは、Goプログラムの実行を支える基盤であり、メモリ管理、ガベージコレクション、スケジューリング、プリミティブ型の実装など、多岐にわたる機能を提供しています。map型はGo言語の組み込み型であり、その効率的な実装はGoプログラム全体のパフォーマンスに直結します。

このコミットが行われた2013年頃のGoランタイムは、現在と比較してまだ発展途上にありました。メモリ割り当て関数も進化の過程にあり、より汎用的な runtime·mallocgc から、特定の用途に特化した、より効率的で型安全な割り当て関数への移行が進められていました。

hashmap.h の削除は、Goランタイムの内部構造の整理の一環と考えられます。特定の機能に特化したヘッダーファイルが、より汎用的なヘッダーに統合されたり、その内容が直接ソースファイル内にインライン化されたりすることで、依存関係が簡素化され、ビルドシステムやコードベース全体の管理が容易になります。

runtime·mallocgc から runtime·cnew/runtime·cnewarray への移行は、Goランタイムのメモリ割り当て戦略の洗練を示しています。mallocgc はガベージコレクタと連携する汎用的なメモリ割り当て関数ですが、cnew と cnewarray はそれぞれ単一のオブジェクトとオブジェクトの配列を割り当てるための、よりセマンティックな関数です。これらの関数は、割り当てるオブジェクトの型情報を直接引数として受け取るため、ガベージコレクタがオブジェクトのレイアウトをより正確に把握し、効率的なマーク＆スイープ処理を行うのに役立ちます。また、これらの関数は割り当てられたメモリをゼロ初期化する責任も負っており、Goのゼロ値保証を効率的に実現します。

前提知識の解説

Goランタイム (Go Runtime)

Goランタイムは、Goプログラムの実行を管理する低レベルのシステムです。これには、ガベージコレクタ (GC)、ゴルーチン (goroutine) スケジューラ、チャネル (channel) の実装、メモリ割り当て、プリミティブ型の内部表現などが含まれます。Goプログラムは、コンパイル時にGoランタイムとリンクされ、ランタイムの機能を利用して実行されます。

ガベージコレクタ (Garbage Collector, GC)

Go言語は自動メモリ管理を採用しており、ガベージコレクタが不要になったメモリを自動的に解放します。GoのGCは、並行マーク＆スイープ方式を基本としており、プログラムの実行と並行して動作することで、アプリケーションの一時停止（ストップ・ザ・ワールド）時間を最小限に抑えるように設計されています。GCが効率的に動作するためには、メモリ割り当て時にオブジェクトの型情報が正確に提供されることが重要です。

runtime·mallocgc

これは、Goランタイム内部で使用される汎用的なメモリ割り当て関数の一つでした。mallocgc は "malloc with garbage collection" を意味し、ガベージコレクタによって管理されるヒープメモリを割り当てるために使用されます。この関数は、割り当てるメモリのサイズ、およびガベージコレクタがオブジェクトのポインタを識別するために使用する型情報（TypeInfo）を引数として受け取ります。

runtime·cnew と runtime·cnewarray

これらは、Goランタイム内部で使用される、より特化したメモリ割り当て関数です。

• runtime·cnew(Type *typ): 指定された型 typ の単一のオブジェクトを割り当て、そのメモリをゼロ初期化します。
• runtime·cnewarray(Type *typ, uintptr count): 指定された型 typ のオブジェクトを count 個含む配列を割り当て、そのメモリをゼロ初期化します。

これらの関数は、mallocgc と比較して、割り当てるデータの「型」をより明確に表現できるため、ランタイムコードの意図が明確になり、ガベージコレクタへの情報提供もより直接的になります。

Hmap 構造体とマップのバケット割り当て

Goのmap型は、内部的にはハッシュテーブルとして実装されています。このハッシュテーブルの主要なデータ構造が Hmap です。Hmap は、キーと値のペアを格納する「バケット」と呼ばれる固定サイズの配列を指し示します。マップのサイズが大きくなると、新しいバケットが割り当てられ、既存の要素が新しいバケットに再配置（evacuate）されることで、マップは動的に拡張されます。このバケットの割り当てに、以前は mallocgc が使用されていましたが、このコミットで cnewarray や cnew に置き換えられました。

技術的詳細

このコミットの技術的な核心は、Goランタイムのメモリ割り当て戦略の洗練と、それに伴うコードのクリーンアップです。

1. hashmap.h の削除: src/pkg/runtime/hashmap.h は、ハッシュマップの実装に関連する型定義や関数プロトタイプを含んでいたと考えられます。このヘッダーファイルが削除されたということは、その内容が不要になったか、あるいは他のより汎用的なヘッダーファイルに統合されたことを意味します。Goランタイムの進化の過程で、内部APIの整理やモジュール化が進められる中で、このようなヘッダーファイルの統合や削除は一般的なクリーンアップ作業です。これにより、ビルド時の依存関係が減少し、コードベース全体の管理が容易になります。

2. runtime·mallocgc から runtime·cnew/runtime·cnewarray への移行: これは、メモリ割り当てのセマンティクスを改善する重要な変更です。

   • 型安全性の向上: mallocgc は、割り当てるメモリのサイズと、ガベージコレクタが使用する型情報（TypeInfo_Array などのフラグを含む）を引数として受け取ります。これに対し、cnew と cnewarray は、割り当てるオブジェクトの具体的な Type ポインタを直接引数として受け取ります。これにより、割り当てられるメモリがどのような型のオブジェクトであるかが、関数シグネチャからより明確になります。これは、コンパイル時またはランタイム時の型チェックを強化し、潜在的なバグを減らすのに役立ちます。
   • ガベージコレクションの効率化: cnew や cnewarray のように、割り当て時に正確な型情報が提供されることで、ガベージコレクタはヒープ上のオブジェクトのレイアウトをより効率的に解析できます。これにより、ポインタのスキャンが高速化され、GCのパフォーマンスが向上する可能性があります。
   • コードの簡素化と可読性: mallocgc を使用する場合、配列の割り当てには TypeInfo_Array フラグを立てる必要がありましたが、cnewarray を使用することで、配列の割り当てであることが関数名から一目瞭然となり、コードがより直感的になります。また、サイズ計算の一部が cnew/cnewarray の内部にカプセル化されるため、呼び出し側のコードが簡素化されます。
   • ゼロ初期化の保証: Go言語では、新しく割り当てられたメモリはゼロ値で初期化されることが保証されています。cnew と cnewarray は、このゼロ初期化の責任を内部で処理します。これにより、mallocgc を使用した場合に別途ゼロ初期化の処理が必要だったり、その保証が曖昧だったりするケースが解消され、コードの一貫性が保たれます。

この変更は、Goランタイムがより成熟し、メモリ管理の内部実装がより洗練されていく過程の一部を示しています。特定の用途に特化した割り当て関数を導入することで、汎用的な関数では実現しにくい最適化や、コードの明確化を図っています。

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

このコミットにおける主要なコード変更は、src/pkg/runtime/hashmap.c および src/pkg/runtime/mgc0.c から hashmap.h のインクルードを削除し、src/pkg/runtime/hashmap.c 内のメモリ割り当て関数呼び出しを runtime·mallocgc から runtime·cnew または runtime·cnewarray に変更した点です。

src/pkg/runtime/hashmap.c

• hashmap.h のインクルード削除:

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -5,7 +5,6 @@
   #include "runtime.h"
   #include "arch_GOARCH.h"
   #include "malloc.h"
  -#include "hashmap.h"
   #include "type.h"
   #include "race.h"
   #include "../../cmd/ld/textflag.h"
  

• hash_init 関数内での変更: マップの初期化時にバケットを割り当てる部分で runtime·mallocgc が runtime·cnewarray に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -255,7 +254,7 @@ hash_init(MapType *t, Hmap *h, uint32 hint)
   		// done lazily later.
   		buckets = nil;
   	} else {
  -		buckets = runtime·mallocgc(bucketsize << B, (uintptr)t->bucket | TypeInfo_Array, 0);
  +		buckets = runtime·cnewarray(t->bucket, (uintptr)1 << B);
   	}
   
   	// initialize Hmap
  

• evacuate 関数内での変更: マップの再ハッシュ（evacuation）時に新しいオーバーフローバケットを割り当てる部分で runtime·mallocgc が runtime·cnew に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -317,7 +316,7 @@ evacuate(MapType *t, Hmap *h, uintptr oldbucket)
   			if((hash & newbit) == 0) {
   				if(xi == BUCKETSIZE) {
   					if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -					newx = runtime·mallocgc(h->bucketsize, (uintptr)t->bucket, 0);
  +					newx = runtime·cnew(t->bucket);
   					x->overflow = newx;
   					x = newx;
   					xi = 0;
  @@ -341,7 +340,7 @@ evacuate(MapType *t, Hmap *h, uintptr oldbucket)
   				} else {
   					if(yi == BUCKETSIZE) {
   						if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -						newy = runtime·mallocgc(h->bucketsize, (uintptr)t->bucket, 0);
  +						newy = runtime·cnew(t->bucket);
   						y->overflow = newy;
   						y = newy;
   						yi = 0;
  

• hash_grow 関数内での変更: マップの拡張時に新しいバケット配列を割り当てる部分で runtime·mallocgc が runtime·cnewarray に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -419,7 +418,7 @@ hash_grow(MapType *t, Hmap *h)
    	old_buckets = h->buckets;
    	// NOTE: this could be a big malloc, but since we don't need zeroing it is probably fast.
    	if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -	new_buckets = runtime·mallocgc((uintptr)h->bucketsize << (h->B + 1), (uintptr)t->bucket | TypeInfo_Array, 0);
  +	new_buckets = runtime·cnewarray(t->bucket, (uintptr)1 << (h->B + 1));
    	flags = (h->flags & ~(Iterator | OldIterator));
    	if((h->flags & Iterator) != 0)
    		flags |= OldIterator;
  

• hash_insert 関数内での変更: 新しいバケットの割り当て、キーや値のメモリ割り当て部分で runtime·mallocgc が runtime·cnew または runtime·cnewarray に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -578,7 +577,7 @@ hash_insert(MapType *t, Hmap *h, void *key, void *value)
    	hash = h->hash0;
    	t->key->alg->hash(&hash, t->key->size, key);
    	if(h->buckets == nil)
  -		h->buckets = runtime·mallocgc(h->bucketsize, (uintptr)t->bucket | TypeInfo_Array, 0);
  +		h->buckets = runtime·cnewarray(t->bucket, 1);
   
     again:
    	bucket = hash & (((uintptr)1 << h->B) - 1);
  @@ -625,7 +624,7 @@ hash_insert(MapType *t, Hmap *h, void *key, void *value)
    	if(inserti == nil) {
    		// all current buckets are full, allocate a new one.
    		if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -		newb = runtime·mallocgc(h->bucketsize, (uintptr)t->bucket, 0);
  +		newb = runtime·cnew(t->bucket);
    		b->overflow = newb;
    		inserti = newb->tophash;
    		insertk = newb->data;
  @@ -635,13 +634,13 @@ hash_insert(MapType *t, Hmap *h, void *key, void *value)
    	// store new key/value at insert position
    	if((h->flags & IndirectKey) != 0) {
    		if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -		kmem = runtime·mallocgc(t->key->size, (uintptr)t->key, 0);
  +		kmem = runtime·cnew(t->key);
    		*(byte**)insertk = kmem;
    		insertk = kmem;
    	}
    	if((h->flags & IndirectValue) != 0) {
    		if(checkgc) mstats.next_gc = mstats.heap_alloc;
  -		vmem = runtime·mallocgc(t->elem->size, (uintptr)t->elem, 0);
  +		vmem = runtime·cnew(t->elem);
    		*(byte**)insertv = vmem;
    		insertv = vmem;
    	}
  

• runtime·makemap_c 関数内での変更: 新しい Hmap 構造体自体を割り当てる部分で runtime·mallocgc が runtime·cnew に変更されています。

  --- a/src/pkg/runtime/hashmap.c
  +++ b/src/pkg/runtime/hashmap.c
  @@ -929,7 +928,7 @@ runtime·makemap_c(MapType *typ, int64 hint)
    	if(key->alg->hash == runtime·nohash)
    		runtime·throw("runtime.makemap: unsupported map key type");
    
  -	h = runtime·mallocgc(sizeof(*h), (uintptr)typ->hmap, 0);
  +	h = runtime·cnew(typ->hmap);
    	hash_init(typ, h, hint);
    
    	// these calculations are compiler dependent.
  

src/pkg/runtime/hashmap.h

• ファイル全体の削除:

  --- a/src/pkg/runtime/hashmap.h
  +++ /dev/null
  @@ -1,4 +0,0 @@
  -// Copyright 2009 The Go Authors. All rights reserved.
  -// Use of this source code is governed by a BSD-style
  -// license that can be found in the LICENSE file.
  -
  

src/pkg/runtime/mgc0.c

• hashmap.h のインクルード削除:

  --- a/src/pkg/runtime/mgc0.c
  +++ b/src/pkg/runtime/mgc0.c
  @@ -12,7 +12,6 @@
   #include "race.h"
   #include "type.h"
   #include "typekind.h"
  -#include "hashmap.h"
   #include "funcdata.h"
   #include "../../cmd/ld/textflag.h"
  

コアとなるコードの解説

このコミットのコード変更は、Goランタイムのメモリ割り当ての内部メカニズムをより洗練されたものにするためのものです。

1. hashmap.h の削除: これは、hashmap.c と mgc0.c の両方から hashmap.h のインクルードが削除されたことを意味します。このヘッダーファイルは、おそらくハッシュマップの内部構造や関連関数の宣言を含んでいましたが、その内容が不要になったか、あるいは他の場所（例えば、runtime.h や type.h など、より汎用的なヘッダー）に統合されたため、独立したヘッダーファイルとしての役割を終えたと考えられます。これにより、コードベースの依存関係が簡素化され、保守性が向上します。

2. runtime·mallocgc から runtime·cnew/runtime·cnewarray への置き換え: これは最も重要な変更点です。

   • runtime·mallocgc(size, typeinfo, flags): この関数は、指定された size のメモリを割り当て、ガベージコレクタが使用する typeinfo と flags を渡します。TypeInfo_Array のようなフラグは、割り当てられたメモリが配列であることをGCに伝えるために使用されていました。
   • runtime·cnew(Type *typ): この関数は、単一のオブジェクトを割り当てるために使用されます。引数として直接 Type ポインタを受け取るため、割り当てるオブジェクトの型が明確になります。例えば、runtime·mallocgc(h->bucketsize, (uintptr)t->bucket, 0) は runtime·cnew(t->bucket) に置き換えられています。これは、t->bucket が単一のバケットオブジェクトの型を表しているため、cnew が適切です。
   • runtime·cnewarray(Type *typ, uintptr count): この関数は、指定された型のオブジェクトの配列を割り当てるために使用されます。引数として Type ポインタと要素数 count を受け取ります。例えば、runtime·mallocgc(bucketsize << B, (uintptr)t->bucket | TypeInfo_Array, 0) は runtime·cnewarray(t->bucket, (uintptr)1 << B) に置き換えられています。ここで (uintptr)1 << B は配列の要素数を表しており、t->bucket は配列の各要素の型を表しています。

この変更により、メモリ割り当ての意図がコード上でより明確になります。単一のオブジェクトを割り当てるのか、それとも配列を割り当てるのかが、呼び出す関数名から直接理解できるようになります。また、型情報がより直接的に渡されるため、ガベージコレクタがヒープ上のオブジェクトをより効率的に追跡し、メモリ管理の精度とパフォーマンスが向上する可能性があります。これは、Goランタイムが内部的に型システムをより深く活用し、メモリ割り当てを最適化していく方向性を示しています。

関連リンク

• Go言語の公式ドキュメント: https://golang.org/doc/
• Goランタイムのソースコード (GitHub): https://github.com/golang/go/tree/master/src/runtime
• Go言語のマップに関するブログ記事 (Go Blog): https://go.dev/blog/maps (このコミットより後の記事ですが、マップの内部構造を理解するのに役立ちます)

参考にした情報源リンク

• Go言語のコミット履歴 (GitHub): https://github.com/golang/go/commits/master
• Go Code Review (Gerrit): https://go-review.googlesource.com/ (コミットメッセージに記載されているCLリンク https://golang.org/cl/13396045 は、このGerritインスタンスへのリンクです)
• Go言語のメモリ管理とGCに関する一般的な情報源 (例: 各種技術ブログ、カンファレンス発表など)
  • Goのメモリ割り当てとGCの進化に関する記事 (例: "Go's Memory Allocator" by Dmitry Vyukov, "The Go garbage collector: prior to Go 1.5" by Rick Hudson)
  • Goのマップ実装に関する詳細な解説記事 (例: "Go maps in action" by Dave Cheney)

これらの情報源は、Goランタイムの内部動作、特にメモリ管理とデータ構造の実装に関する理解を深めるために参照しました。