swiftメモリオーナシップのマニフェストが公開

Swiftの開発者で、Tesla移籍までSwiftチームのリーダを務めていたChrid Lattner氏によると、Swift 4の主な目標のひとつに、Rust/Cycloneからヒントを得たメモリオーナシップモデルの定義がある。Swift 4がフェーズ2に入った今、Swiftチームは、Swiftのメモリオーナシップの動作を説明したマニフェストを発表した。

実はSwiftのコンパイラには、オーナシップ移行の必要性を判断するために、独自のオーナシップモデル的なもの(ARC)がすでに備えられており、オーナシップが明確な場合や、あるいはコンパイラが誤った仮定を行なったために、不必要なコピーが発生することがある。一言で言えば、Swiftの新しいメモリオーナシップモデルは、このメモリがコピーされたときの処理を開発者の管理下に置こうとするものだ。Swiftにおけるメモリオーナシップモデル定義の主な目的は、現在のコピー・オン・ライト参照カウントのアプローチに存在する欠点を克服することにある。これらはオーバーヘッドであり、参照カウントのパフォーマンスを予測不可能なものにする場合があると同時に、常にコピー可能であるという要件により、一般的にメモリのアロケーションを必要とする。

このような欠点は、通常のアプリケーションプログラムでは問題にならないものの、パフォーマンス上の保証が必要とされるシステムプログラミングにおいては寛容できない場合もある。それに加えて、より柔軟なメモリ管理モデルを導入することのメリットは、アプリケーションプログラミングにおいても、ある種のボトルネックを克服しようとする場合には重要となる。Swiftの新たなメモリオーナシップモデルはオプトインに基づいている。すなわち、ARCと比較した場合、詳細な管理を必要とする開発者のみが、その複雑性というコストを甘受することになる。

すべてのSwift開発者に影響を与えるであろう変更のひとつは“独占の法則(Law of exclusivity)”で、」これはオプトインではない。この法則はひとつの変数に対して、競合的な方法で同時にアクセスできないように強制するものだ。２つの異なる関数にinout引数として渡される場合、メソッドがコールされた時と同じ変数にアクセスするコールバックをメソッドが受信した場合、などがこれにあたる。いずれも現在のSwiftでは認められているので、これらを除外することは、すべての開発者に影響するはずだ。さらに、パラメータに対する保証が変更されることにより、独占の法則は言語ABIにも影響を与える。採用時には、これが最初に気付く特徴のひとつになるだろう。

“独占の法則”以外にも、新たなアノテーション、および値の共有に関する指示と暗黙的なコピーを不可とする型の表現を行なう言語機能が導入される。これら３つのメカニズム - 独占、共有値伝搬の明示的コントロール、コピー不可な型 - が相まって、コンパイラのより積極的なコード最適化を可能にする、とマニフェストの筆者は記している。

簡単に言えば、Swiftの新たなオーナシップモデルの全体像は、次のように要約することができる。

• 前述のようにコンパイラは、明示的あるいは暗黙的な方法で、inoutのすべてに非排他的な使用をフラグする。
• 開発者が変数の占有(owned)または共有(shared)を定義することで、レキシカルスコープに対する入出時の参照カウントと不要なコピー/廃棄の回避が可能になる。
• 開発者はmoveonly(すなわちコピー不可)型を宣言することができる。コンパイラはこれをコピーせず、新たな参照の作成に使用することも不可能になる。moveonly型は移動のセマンティクス(move semantics)を備えるが、これは高度な機能と見なされるため、デフォルトではすべての型がコピー可能とされる。

マニフェスト自体は膨大なもので、このオーナシップモデルの定義がSwiftに与える影響をあらゆる面から詳しく分析しているが、詳細な部分については必ずしも最終的なものではない。それよりも簡潔だが、キーポイントを非常によく押さえた要約が、Swift開発者のAlexis beingessener氏によって公開されている。