質問の歴史
歴史的に、システムプログラミングにおける識別されたユニオンは、バリアントケースを区別するために明示的なタグフィールドや手動のメモリレイアウトを必要としました。Swiftは、Objective-Cの安全なユニオンが欠如していたことから進化し、型安全性を保証しつつメモリ効率を最大化するために、コンパイラ管理のenumレイアウトアプローチを必要としました。初期バージョンのSwiftは、追加の住人を使って単一ペイロードenum（例えば、Optional）を最適化しましたが、マルチペイロードシナリオでは、単純なタグバイトプレフィックスに伴うメモリの膨張を回避するために、より高度なビットレベルの分析が必要でした。
問題
enumが異なる関連ペイロードタイプを持つ複数のケースを持つ場合（例：case text(String), number(Int), data([UInt8])）、コンパイラはランタイムパターンマッチング中にどのケースがアクティブであるかを決定するのに十分な情報を保存しなければなりません。単に識別子バイトを前に追加することは、特に小さなペイロードに対して合計サイズを大きく増加させ、メモリフットプリントが重要なCスタイルのユニオンとのABI互換性を破ります。課題は、ケース識別子を拡張せずにペイロードタイプ内で未使用のビットパターン（予備ビット）を利用してエンコードすることにあります。
解決策
Swiftは、まずすべてのペイロードタイプ間の未使用ビットパターン（予備ビット）の交差を計算するマルチペイロードenumレイアウト戦略を採用しています。十分な予備ビットが存在する場合、例えば、Stringが小さな文字列最適化ビットを使用する場合や参照型がポインタアラインメントギャップを使用する場合、コンパイラはこれらのビット内にケースタグを直接保存し、最大のペイロードのサイズを維持します。ペイロードタイプが利用可能な予備ビットを使い果たすと（例：アラインメントに余裕のない二つのInt64ペイロード）、コンパイラは表示するための追加バイト（またはワード）を追加して、オーバーヘッドを最小化しつつ、明確なケース識別を保証します。
問題の説明
リアルタイムゲームクライアント用の高スループットネットワークパケットパーサーを開発する際、チームはPacket enumを定義しました。このenumにはping(Int64)、payload(Data)、error(UInt8)のケースがあります。プロファイリングの結果、enumのメモリフットプリントが暗黙的な識別子フィールドによりL1キャッシュラインを超えてしまい、パケットバッチ処理中にキャッシュのトラッシングを引き起こし、レイテンシが16msのフレーム予算を超えてしまうことが判明しました。
検討された異なる解決策
解決策1: 生バイトによる手動ユニオン
チームは、UnsafeMutablePointerを使用してペイロードを別のタグでstructに手動で重ねることを検討しました。これはCユニオンを模倣しました。このアプローチは、ケース区別にオーバーヘッドがないことを提供しましたが、Swiftの型安全性を犠牲にし、非同期ネットワークコールバックを処理する際に解放後の使用エラーのリスクを増加させる手動メモリ管理を必要としました。さらに、この解決策はARC統合を破壊し、参照カウントされたペイロード（例えば、Data）のための手動保持/解放呼び出しを必要としました。
解決策2: プロトコルベースの型消去
別のアプローチは、enumをPacketプロトコルに置き換え、存在容器（any Packet）またはジェネリクスを使用することでした。このアプローチは抽象化を保持しましたが、存在容器のボクシングによるヒープ割り当てと仮想メソッドディスパッチのオーバーヘッドを導入しました。パフォーマンスの低下はホットパスにとって受け入れられないもので、割り当て頻度が二倍になり、Swiftランタイムに対するガーベジコレクションの圧力を引き起こしました。
選択した解決策
チームは、ケースを並べ替え、固有の予備ビットを持つペイロードタイプを使用することでSwiftのマルチペイロード最適化を活用するようにenumをリファクタリングしました。彼らはInt64をカスタムUInt56構造体（上位バイトを予約）に置き換え、errorがより大きなペイロードの予備ビットパターンに合わせてUInt32を使用することを確実にしました。これにより、コンパイラはDataとUInt56ペイロードの予備ビットにケース識別子をパックでき、追加のバイトを排除し、enumのサイズを24バイトから16バイトに削減しました。
結果
最適化により、パケットパーサーは単一キャッシュライン内でバッチを処理でき、フレームレイテンシが40%削減され、enum自体のメモリ割り当てオーバーヘッドが排除されました。コードは、危険なポインタやプロトコル型消去に頼ることなく完全な型安全性とパターンマッチ機能を維持しました。
Swiftのenumレイアウト戦略は、ヘッダーからのユニオンをインポートする際にC互換性とどう相互作用しますか？
SwiftがClangヘッダーを介してCユニオンをインポートする場合、それはその型をすべてのユニオンメンバーのタプルを含む単一ケースとしてenumとして扱うか、そうでない場合は@_NonBitwiseとしてマークされている場合はそのように扱います。しかし、SwiftはCユニオンのインポートに対してマルチペイロードの予備ビット最適化を適用することはできません。なぜなら、CユニオンはSwiftの型メタデータや確定初期化保証が不足しているためです。コンパイラは、Cユニオンの任意のビットパターンが有効であると仮定する必要があり、ケース識別に予備ビットを使用することができません。候補者はしばしばSwiftがCユニオンフィールドを再秩序化したり、暗黙的なタグを追加したりするという誤解を持ちます。代わりに、SwiftはCレイアウトを正確に保持し、Swift enum最適化の利点を得るためには、明示的な管理がOptionSetパターンや手動のstructラッピングを通じて必要です。
頑健なマルチペイロードenumに新しいケースを追加することが時折コンパイラに予備ビット最適化を完全に放棄させるのはなぜですか？
頑健モジュール（ライブラリ進化が有効化されてコンパイルされた）はABIの安定性を維持しなければならず、それはenumのレイアウトがバイナリ互換性を破る方法で変更できないことを意味します。将来のライブラリバージョンでマルチペイロードenumに新しいケースが追加され、その新しいペイロードタイプが利用可能な予備ビットを最後まで消耗すると、コンパイラは拡張されたケース空間に対応するために明示的な識別子バイトにフォールバックしなければなりません。元のレイアウトが頑健モジュールのメタデータで固定されているため、コンパイラは既存のペイロードからビットを遡及的に回収することができません。候補者はしばしば、頑健性の境界が公開インターフェースだけでなく、内部のビットレイアウトヒューリスティクスを固定することを理解せず、パフォーマンスに重要なenumで予備ビット最適化がバージョン間で持続することを保証するために手動の@frozen属性が必要になることを見落とします。
コンパイラはケース区別のために「追加の住人」と「予備ビット」をどのように使用し、そのことがenumメモリアラインメントにどのように影響を与えますか？
追加の住人は、単一の型内の無効なビットパターン（参照型のnilポインタやOptionalのnoneケースなど）を指し、予備ビットはマルチペイロードenum内の複数のペイロードタイプ間で共有される未使用のビットパターンです。単一ペイロードenumの場合、コンパイラは他のケースを表すためにペイロードの追加の住人を使用します。マルチペイロードenumの場合、コンパイラはすべてのペイロード間の予備ビットの交差を計算します。アラインメント制約はこれを複雑にします。異なるペイロードで異なるオフセットに予備ビットが存在する場合、コンパイラはパディングを追加したり、整列を一貫して保つためにオーバーフロウタグを使用する必要があるかもしれません。候補者はしばしばこれら二つの概念を混同し、追加の住人が単一ペイロードシナリオ（例えばOptional<T>）を最適化し、予備ビットがマルチペイロードシナリオを最適化することを理解せず、それらを混在させることが最大ペイロードのアラインメント要件を慎重に考慮することを要することに気づきません。