Objective-Cランタイムの進化

Objective-Cランタイムの進化

Objective-CやSwiftクラスの基礎となる、低レベルのビットやバイトのミクロの世界に飛び込んでみましょう。内部のデータ構造、メソッド一覧、タグ付きポインタに対する最近の変更がどのようにパフォーマンスの改善やメモリー使用量の減少につながっているかをお伝えします。内部の個々の要素に依存するコードにおけるクラッシュの認識および解決方法を紹介し、ランタイムに対する変更に影響されないコードの維持方法もお伝えします。

リソース
- Objective-C Runtime
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC20
- 安全でないSwift
ダウンロード

“ようこそ　WWDCへ” こんにちは　WWDCへようこそ
“Objective-Cランタイムの進化” ランタイムチームのベンです本日紹介するのはiOSとmac OSでの Objective-Cランタイムの変更点ですメモリの使用が改善されます今日の話は他と違い― コードの変更は不要です新しいAPIや非推奨の警告の話はしません運がよければ何もせずにアプリケーションが速くなりますこれらの改善について話す理由はクールで興味深いからですまたランタイムの改善が可能なのが我々の内部データ構造が APIの背後に隠されているからですデータ構造に直接アクセスするとクラッシュが多くなりますあなたのコードベースで作業する人が不適切なアクセスをした時に注意すべきことをお伝えします３つの変化を見ていきます最初は Objective-Cランタイムがクラスの監視に使うデータ構造の変化です次が Objective-Cのメソッドのリストの変化最後がタグ付きポインタの記述の変化です
ではクラスのランタイムデータの変化から始めますアプリケーションのバイナリでクラスはこう見えますまずクラスオブジェクトです頻繁にアクセスする情報が含まれますメタクラスとスーパークラスとメソッドキャッシュへのポインタですデータへのポインタもあります詳しい情報が格納されたclass_ro_tです “ro”は読み取り専用の意味ですここに含まれるのはクラス名― メソッドやプロトコルやインスタンス変数の情報です
この基礎構造は SwiftとObjective-Cに共通で Swiftの各クラスは同じデータ構造を持ちますクラスはディスクからメモリにロードされ最初はこの形ですが使い始めると変わりますこのことを理解するためにクリーンなメモリとダーティなメモリの違いを知るのがいいでしょうクリーンなメモリはロードされても変わりません class_ro_tは読み取り専用なのでクリーンですダーティメモリはプロセス実行中に変化します
クラス構造がダーティなのはランタイムが新しいデータを書き込むからです新しいメソッドキャッシュやポインタを生成します
ダーティメモリのほうがクリーンより高価ですプロセス実行中は必ず使い続けます
一方空き容量を作るためクリーンメモリは解放できます必要であればいつでも再ロードできるからです
macOSはダーティメモリをスワップアウトできますがスワップ機能のないiOSではダーティメモリはコストがかかります
ダーティメモリのせいでこのクラスデータは２分割されますデータはクリーンなほうがいい変化しないデータを分割すればクラスデータの大分部はクリーンなメモリのままです
最初のデータで十分でもランタイムは各クラスの情報がさらに必要ですクラスが使われ始めると― ランタイムはさらにストレージを割り当てます
この割り当てられたストレージはデータの読み書き用のclass_rw_tですランタイムで生成された新しい情報だけを格納しますサブクラスと兄弟クラスのポインタを使い― すべてのクラスをツリー構造でつなげますランタイムは使用中の全クラスをトラバースできメソッドキャッシュの無効に役立ちます
メソッドとプロパティは読み取り専用ですがこのクラスにありますランタイムで変化するからですロードされたカテゴリが新しいメソッドをクラスに加えますランタイムAPIを動的に使いこのメソッドを加えられます class_ro_tは読み取り専用なので class_rw_tでこれらの監視が必要です
これはかなりのメモリを使用しますどのデバイスでも多くのクラスを使います iPhoneのシステムで class_rw_t構造は 30MBになりますどう削減できるでしょう？これらはランタイムで変化するので読み書き部分に格納します
でも使用量を調べると― クラスの10％ほどしかメソッドは変化していません
デマングルされた名前は Swiftのクラスだけが使います Objective-Cの名前が不要なら Swiftのクラスでも使いません
だから使われない部分を分割しますこれでclass_rw_tが半分になりますさらに情報が必要なクラスに拡張されたレコードの１つを割り当て― クラス全体に加えて使用します
クラスの約90％はこの拡張されたデータは不要でシステムの14MBを節約していますアプリケーションのデータ保存などに有効に使えるメモリですターミナルで簡単なコマンドを実行すればこの変化の影響が分かります実際にやってみます MacBookのターミナルで― どのMacでも使えるヒープというコマンドを実行します実行中のプロセスで使用中のヒープメモリを調べますではメールのアプリケーションで実行しましょうこのままだとメールのヒープの割り当てを表す― 大量の行が出力されます今日話題にしているタイプで― grep検索を行います class_rw_tですヘッダも検索します
検索結果によると 9000のclass_rw_tをメールで使っていることが分かりますしかし拡張された情報が必要なのは 10分の１の約900だけですこの変化で節約したサイズを計算できますこのタイプは２分割されましたこの数字から差し引くのが拡張されたタイプに割り当てたメモリですメールだけでデータの約250キロバイトを節約しましたこれをシステム全体で行えばダーティメモリに関してかなりの節約ですクラスからデータをフェッチするコードは拡張されたデータを持つクラスと持たないクラスに対処しますランタイムがすべて処理します表面的にはすべて前と同じ働きをしメモリの使用が減りますこれらの構造を読み込むコードがランタイム内にありアップデートされているからですこれらのAPIが重要になりますデータ構造に直接アクセスしようとするコードは今年リリースのOSで使えません新しいレイアウトに対応していないからですこれらの変化で壊れたコードもあります自分のコードだけでなくアプリケーションの外部依存関係にも注意しましょう知らぬ間にデータ構造を使うかもしれません
これらの構造の情報はすべて公式のAPIで有効です class_getNameやclass_getSuperclassの関数がありますこれらのAPIでこの情報にアクセスする時― シーンの背景で何を変えても APIは機能し続けますこれらのAPIの説明は developer.apple.comのドキュメントにあります次にクラスのデータ構造を詳しく見て Relative Method Listsを説明しますクラスごとにメソッドのリストがあり新しいメソッドを書き込むと追加されますランタイムはこのリストを使い情報を送ります各メソッドには情報が３つずつありますまずメソッド名またはセレクタですセレクタは独特な文字列で pointer equalityとも比較されます
次にメソッドのtype encodingですこれはパラメータや戻り値の型を表す文字列で情報は送りませんが― ランタイム･イントロスペクションやフォワーディングに必要です
最後はメソッドをインプリメントするポインタで実際のコードですメソッドを書き込むとC関数にコンパイルされますそして関数ごとにメソッドのリストに加わります一例を見せましょう初期化のメソッドですメソッド名とデータ型インプリメントが見えますね
リストのデータそれぞれがポインタです 64ビットならそれぞれのテーブル項目を 24バイトが占めていますクリーンメモリですがフリーなままとはいかず― 使用時にはディスクからロードしてメモリを使います
これがプロセス中のメモリを拡大した様子です原寸ではありません 64ビットのアドレスのため大きなアドレス空間がありますアドレス空間にはスタックやヒープの他に― 実行ファイルやライブラリ２値画像がプロセスにロードされます青色の部分です
２値画像の１つを拡大して見てみましょうここではメソッドの３つのエントリーが２値画像を指していますここでコストがかかります２値画像は動的なリンカが決定した場所でメモリにロードされますリンカはポインタをイメージに解像し修復しなければなりませんこれはロード時にメモリ内の実際のロケーションを示すためですバイナリからのクラスメソッドのエントリーはそのバイナリだけでインプリメントされますあるバイナリのメタデータやコードを持つメソッドを― 他にインプリメントはできませんリストに載せるものは 64ビットのアドレス空間全体に― 関連する必要はないということですリストは関連したバイナリの関数に準ずればいいので常に近くにあります
つまり64ビットの絶対アドレスではなく― 32ビットの相対アドレスをオフセットで使うこともできますこれが今年変更した部分ですいくつか利点がありますロードした場所に関係なくオフセットはいつも同じなので― ディスクからロードした後修復の必要はありません修復しないので読み取り専用メモリとしてさらに安全性が高くなります 32ビットのオフセットを使うことで 64ビットの半分のメモリしか必要としません調べたところ普通のiPhoneのシステム全体は 80MBなので― このメソッドなら半分の40MBを節約できますアプリケーションのユーザーに余裕ができます
では swizzleは？バイナリ内のメソッドはアドレス空間全体を使えませんが― swizzleすればどこでもインプリメントできますそれにメソッドのリストを読み取り専用にしておきたいので― global table mappingのメソッドを swizzleのインプリメントに使いますメソッドの大半は swizzleされないので― このテーブルはさほど大きくなりません小さい分メモリがダーティになるのは１ページごとで済みます以前のメソッドなら swizzleでページ全体がダーティになります単独のswizzleが大量のダーティメモリを生むのです１つのテーブルのせいで余計なコストを払います今回の改良点も皆さんの目には触れず使い心地は変わりません Relative Method Listsは今年登場するOSでサポートされます最小デプロイ･ターゲットでビルドするなら― ツールはバイナリのリストに自動的に生成されます古いOSが対象の時でも心配は要りません Xcodeが古いリストのフォーマットで生成してフルにサポートします Relative Method Listsの入ったOSの恩恵を受けられ― 新旧のフォーマットでアプリケーションを同時に使っても大丈夫です今年のOSを手に入れればバイナリが小さくなりメモリを節約できます Objective-CやSwiftには朗報です最小デプロイ･ターゲットは SDKやAPIだけの話ではありません Xcodeが古いOSのサポートは不要と認識すると― 最適化したコードやデータを放出します古いバージョンが必要なのは承知ですが― できるタイミングでバージョンアップすることをお勧めします
注意が必要なのは― ビルドの際のデプロイ･ターゲットが対象とするバージョンよりも新しい場合です Xcodeが防ぐはずですが― よそでビルドしたライブラリやフレームワークを取り込むとすり抜けます古いOSで実行するとランタイムがメソッドを認識する時― それが理解できず昔ながらのポインタベースのメソッドで解釈しようとします
つまり32ビットのフィールド２つを 64ビットで読み込もうとするのですその結果２つの整数型で１つのポインタになり― 値として意味を持たないのでクラッシュしますランタイムがクラッシュした時メソッドの情報を読むと― ここに見られるように 32ビットの値が合わさっているので分かります
コードを実行してもこの構造体で値を読み込むので― ランタイムと同じような問題が起きますユーザーがアップグレードするとクラッシュしますそれを避けるには画面のAPIを使ってくださいこれなら背面で何が変わろうとも大丈夫です例えばメソッドのポインタを得てフィールドに値を返す関数もあります
今年のもう１つの変化を見てみましょう ARM64でのタグ付きポインタ形式の変更ですまずタグ付きポインタが何であるか低レベルになりますがご心配なく他の話同様知る必要はありませんでも面白いですメモリ使用率の理解にも役立つかもしれませんまず通常のオブジェクトポインタの構造を見てみましょう通常これらは大きな16進数として出力されますいくつかは先ほど見ました
バイナリ表現に分解してみましょう 64ビットですがすべてのビットを使うわけではありません中間のこれらのビットだけが実際のオブジェクトポインタに設定されますアライメント要件のため下位ビットは常に０ですオブジェクトは常にポインタサイズの倍数のアドレスに配置します
アドレス空間が限られているため上位ビットは常に０です２から64までわたることはありません上位ビットと下位ビットは常に０です常に０のビットのどれかを１にしてみましょうこれで即座に実際のオブジェクトポインタではないと分かり― 次に他のすべてのビットに他の意味を割り当てられますこれをタグ付きポインタと呼びます
例えば数値を他のビットに詰め込むことができます NSNumberにビットの読み方を教えランタイムにタグ付きポインタの適切な処理を教えれば― 残りのシステムはオブジェクトポインタのようにこれらを扱い違いに気づきません同様のすべてのケースに小さな数のオブジェクトを割り当て― オーバーヘッドを節約でき大きな得になります
話が逸れますが― これらの値はプロセスの起動時に初期化されるランダムな値の組み合わせで難読化されていますタグ付きポインタの偽造を困難にするセキュリティ対策です残りの議論では無視しますトップのレイヤーにすぎません値を見てもスクランブルされているだけと覚えておきましょうこれがIntelのタグ付きポインタの完全な形式です下位ビットは１に設定されタグ付きポインタであることを示していますこのビットは実際のポインタでは判別のため常に０でなければなりません
次の３ビットはタグ番号でタグ付きポインタの型を示します例えば３はNSNumberであること６はNSDateであることを意味します３つのタグビットでは８種のタグ型が可能です
残りのビットはペイロード特定の型が好きなように使えるデータです
タグ付けされたNSNumberの場合これは実際の番号です
特別なケースはタグ７ですこれは拡張タグを示します拡張タグは次の８ビットを使って型をエンコードし― さらに256種のタグ型を小さなペイロードで可能にしますデータをより小さなスペースに収められる限りより多くのタグ付きポインタを使用できますこれはタグ付けされたUI色や NSIndexSetに使われます
これが便利だと思った方はガッカリするかもしれませんが― ランタイムメンテナーのAppleしかタグ付きポインタ型を追加できませんしかしSwiftプログラマーなら独自の種類のタグ付きポインタを作成できます関連値がクラスの列挙型を使ったことがあればそれがタグ付きポインタのようなものです Swiftランタイムは列挙型識別子を関連値ペイロードのスペアビットに格納しますさらにSwiftの値型の使用はタグ付きポインタを重要でなくします値を正確にポインタサイズにする必要がなくなるためです例えばSwift UUID型は２語で１列に収められるので― ポインタ内に収まらず別のオブジェクトを割り当てることになりませんこれがIntelのタグ付きポインタです ARMを見てみましょう ARM64では順序が逆になります最下位ビットでなく最上位ビットが１に設定されタグ付きポインタを示します次の３ビットにはタグ番号が入りペイロードが残りのビットを使います ARMのタグ付きポインタを示すのにIntelのように最下位でなく最上位ビットを使う理由は？ objc_msgSendのための小さな最適化です msgSendの最も一般的なパスをできるだけ高速にしたいわけです最も一般的なパスは通常のポインタ用で― 一般的でないケースがタグ付きポインタとnilです
最上位ビットを使うと１回の比較で両方を確認できるので― 別々に確認するより msgSendの一般的ケースの条件付きブランチを節約できます Intelと同様タグ７には特別なケースがあり― 次の８ビットは拡張タグに使われ残りのビットはペイロードに使われます
以上は実はiOS 13で使われていた古い形式で今年のリリースでは少し動かしていますタグビットは最上位のままです msgSend最適化は依然とても役立つからですしかしタグ番号が下位３ビットに移動拡張タグは使用中の場合タグビットに続く上位８ビットを占めますこうした理由？通常のポインタから考えてみましょう
動的リンカなどの既存のツールは― ARMのTop Byte Ignore機能でポインタの上位８ビットを無視しますそして拡張タグを Top Byte Ignoreビットに配置しますアラインされたポインタでは下位３ビットは常に０ですしかしポインタに小さな数を加えるだけでそれをいじることができます下位ビットを１に設定するために７を加えます７はこれが拡張タグであることを示しますつまりこの上のポインタを拡張タグポインタペイロードに収められるのです結果はペイロードに通常のポインタを持つタグ付きポインタですそれが役立つ理由？タグ付きポインタで文字列や他のデータ構造などバイナリの定数データの参照が可能になり― ダーティメモリの占有を避けられますこの変更によって― これらのビットに直接アクセスするコードは今年のiOS 14のリリース後機能しなくなりますこういうビット単位のチェックは以前は機能していましたしかし将来のOSでは誤答を出すようになりアプリケーションがユーザーデータを破損しますそこで今話したようなコードは使用しないで― 代わりに…　お分かりですね APIを使用してください isKindOfClassのような型判定は古いタグ付きポインタ形式で機能し― 新しいタグ付きポインタ形式でも機能し続けます NSStringやNSNumberメソッドはすべて機能し続けますこれらのタグ付きポインタ内の情報はすべて標準APIを通じて取得できます CF型にも当てはまる点も注目に値します我々は何も隠したくないし誰のアプリケーションも壊したくありません詳細を伏せるのはこのような変更を行うための柔軟性を維持するためだけですこれらの内部詳細に依存しない限りアプリケーションは問題なく機能し続けますではまとめましょう今回は舞台裏の改善をいくつかお見せしましたそれでランタイムのオーバーヘッドが減りあなたとユーザーが使えるメモリが増えました何もしなくても改善は得られますがデプロイ･ターゲットを上げることは検討しましょう我々が毎年改善を行うために単純なルールに従ってください内部ビットを直接読み取らず APIを使用することご視聴ありがとう高速デバイスをお楽しみください

5:37 - Use the heap command to calculate memory savings
```
heap Mail | egrep 'class_rw|COUNT'
```

class_getName

class_getSuperclass

class_copyMethodList

14:38 - Use the APIs

method_getName

method_getTypeEncoding

method_getImplementation

21:52 - Use the APIs

if ([obj isKindOfClass:[NSString class]]) {
    // a string
}
NSUInteger length = [obj length];


if (CFGetTypeID(obj) == CFStringGetTypeID()) {
    // a string
}
CFIndex length = CFStringGetLength(obj);

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC20