歴史: Go 1.18以前は、言語にパラメトリックポリモーフィズムが欠けており、開発者はinterface{}（ヒープ割り当てやボクシングオーバーヘッドを引き起こす）とコード生成（バイナリ膨張を引き起こす）の間で選択を強いられていました。ジェネリクスを設計する際、Goチームは、重複したマシンコードを生成する完全なモノモルフィゼーションのC++テンプレートモデルを明示的に拒否しました。これは、数千のパッケージをリンクする大規模なクラウドネイティブアプリケーションにおけるバイナリサイズの爆発に対する懸念からです。
問題: 純粋なモノモルフィゼーションは、64ビット整数であるにもかかわらず、**Process[int]とProcess[uint]**のための別々のアセンブリブロックを生成し、命令キャッシュとディスクスペースを無駄にします。逆に、ボクシングを通じてジェネリクスを実装すること（Javaのように）は、値型をヒープに置かなければならず、Goのシステムプログラミングニッチに欠かせないゼロ割り当ての性能特性を破壊します。課題は、N倍のコード重複問題を回避しつつ、コンパイル時の型安全性とゼロコストの値セマンティクスを保持することにありました。
解決策: Goは、GCシェイプスタンシリングとランタイム辞書を組み合わせて使用しています。コンパイラーは、正確な型の識別ではなく、サイズ、アラインメント、ポインタビットマップによって定義されたGCシェイプによって型をグループ化します。同じメモリレイアウトを持つ型（例: []intと**[]string**、両方ともポインタ、len、capを持つヘッダ構造体）を共有します。メソッドディスパッチや型アサーションのような型固有の操作に対しては、コンパイラーはメタデータオフセットを含む隠れたランタイム辞書を渡します。これにより、**Point{X:1, Y:2}とVector{X:1, Y:2}**はコードを共有しつつ、値型はスタック上でボクシングされません。
私たちは、高性能なカラムストレージエンジンを開発しており、int64タイムスタンプとカスタムDecimal128構造体（16バイト、2つのuint64フィールド）をインデックス付けするためのジェネリックSkipList実装を必要としていました。初期のベンチマークでは、**interface{}**を使用した結果、CPU時間の35%がランタイムのヒープ割り当てとインターフェースの間接参照に消費され、私たちのサブマイクロ秒のレイテンシ要件には受け入れられませんでした。
私たちは、3つのアーキテクチャアプローチを検討しました。まず、go generateとtext/templateを使用して専用のSkipListInt64およびSkipListDecimal実装を生成する完全なモノモルフィゼーション。これにより、割り当ては排除されますが、12種類の異なる数値型をサポートするとバイナリサイズが22MB増加し、サーバーレスデプロイメントの制約に違反します。次に、unsafe.Pointerとリフレクションを使用した統一実装でメモリを手動管理。これにより、バイナリサイズは最小限に保たれましたが、テスト中にGoのガベージコレクタの不変性を破る手動ポインタ算術を必要とする壊滅的な複雑さをもたらしました。
私たちは3番目のアプローチを選択しました: GCシェイプグルーピングに注意を払いながら、ネイティブのGoジェネリクス。Decimal128構造体を**[2]uint64**のメモリレイアウトに揃え、他の16バイトの値型とスタンシルコードを共有するようにしました。go tool objdumpを使用してコンパイラ出力を分析することで、**SkipList[int64]とSkipList[uint64]**が同じアセンブリブロックを共有し、**SkipList[string]**がポインタを含んでいるために別のスタンシルを正しく使用していることを確認しました。このハイブリッドアプローチは、コード生成と比較してバイナリサイズを58%削減し、ゼロ割り当てスループットを維持しました。その結果、**interface{}**バージョンに対して4倍のレイテンシ改善が得られ、バイナリサイズは30MB未満となりました。
なぜ、同一のフィールド型を持つ2つの異なる構造体型が時々別々のジェネリックインスタンスを生成するのに対し、構造体とプリミティブの型エイリアスがコードを共有することがあるのですか？
これは、GCシェイプグルーピングがポインタビットマップとパディングを含む完全なランタイム型記述子に依存しているため発生します。**type A struct { x, y int }とtype B struct { x, y int }**が異なるパッケージで定義されている場合、同じGCシェイプとスタンシルを共有します。しかし、type C struct { x *int; y int }はtype D struct { x, y int }とは異なるポインタビットマップを持つため、別のマシンコード生成が強制されます。一方、type MyInt intとintはシェイプを共有しますが、**struct { _ int; x int }とstruct { x int }**はアラインメントパディングによって異なる場合があります。ガベージコレクタが生存変数の正確なスタックマップを必要とするため、レイアウトアイデンティティが名目型アイデンティティを上回る理由を理解することが重要です。
ジェネリック型パラメーターに対するメソッドディスパッチは、直接的な具体的呼び出しとどのように異なり、このオーバーヘッドがフルモノモルフィゼーションなしでは回避できない理由は何ですか？
ジェネリック型パラメーターTのメソッドを呼び出す際、コンパイラーは直接の関数アドレスではなく、ランタイム辞書を通じて間接呼び出しを生成します。インターフェイス呼び出しとは異なり、ランタイムでitabを介してメソッドを解決しますが、ジェネリック辞書エントリはコンパイル時に解決されますが、隠れたパラメータとして渡されます。これにより、ゼロコストのモノモルフィゼーションコードに比べて、1レベルの間接参照（通常2-5ナノ秒）が追加されます。候補者はしばしば、ジェネリクスが手動専用コードに対して完全にゼロオーバーヘッドであると仮定しますが、実際には辞書ルックアップがモノモルフィゼーションが許可される某些インライン最適化を妨げます。ただし、これはreflect.Value.Callよりも数桁速いままです。
なぜ、空の識別子フィールド（例えば、struct { _ int64; x int64 }）を持つジェネリック型をインスタンス化すると、コンパイラーがユニークなスタンシルを生成する可能性があり、バイナリサイズが増加するのですか？
空のフィールドはスペースを占有し、名前の付いていない場合でも構造体のポインタビットマップに寄与し、GCシェイプを変える可能性があります。*struct { _ int64; x int64 }は、特定のアーキテクチャでstruct { x int64 }とは異なるサイズとアラインメントを持つため、コンパイラは異なるスタンシルグループに割り当てることになります。さらに、空のフィールドがポインタ型（_ int）の場合、それはその型に対するガベージコレクタのトレーシング要件を変更し、別々のスタックマップを義務付けます。バイナリサイズを最適化する開発者は、GCシェイプがパディングや空のフィールドを含む完全なメモリレイアウトによって決定されることを理解する必要があります。