• Like
  • Save
小二病でもGCやりたい
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

小二病でもGCやりたい

  • 1,092 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,092
On SlideShare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 小二病でもGCやりたい 1
  • 2. おやくそく● ID: dec9ue● 属性:組み込みエンジニア● 言語遍歴 – N88-BASIC ← 高校生: PC持ってなかった – SMLNJ/OCaml ← 学生時代:大堀/雅利賀先生 – C++ ← 社会人 – Java ← プロジェクト変わった – C ← 更にプロジェクト変更: お金を稼ぐ気になった – Verilog ← HW開発部署になった、いまここ
  • 3. メニュー● JHCのGC● 本編● エピローグ 3
  • 4. JHCのGC 4
  • 5. JHCのGC● GCにはいろいろあれど。。。 明示的開放 オブジェクト 主な処理系 の移動マークスイープGC あり なし Java(コピーも併用) Dalvik Cruby OCaml参照カウント法 あり なし Cpython(MSも併用)コピーGC なし あり GHC RTS Java(MSも併用)マークコンパクトGC 実施可能 あり Lisp2 5
  • 6. JHCのGC● たいていのGCは複数の機構を併用している● 基本的な理由 – GCの方式によって得意不得意がある● ありがちな要因 – パフォーマンス ● 割り当て機会が多い(割り当てコストの低いコピーGCl) ● 大きなオブジェクトはコピーに弱い(コピーしないマークスイープGC) – ファイナライザが必要(参照カウンタ・マークスイープ) ● 言語機構にファイナライザがある ● FFIやリソースの開放処理を伴う場合 6
  • 7. JHCのGC● ありがちな2種類● Cpython – 参照カウント(コストが実行系側に集約される) – マークスイープ(循環・オーバーフロー回収のため)● GHC – コピー(割り当てが高速) – マークスイープ(LargeObjectやFFIのため) 7
  • 8. JHCのGC● JHCのJGCはまた格別● いわば マークオンリーGC● とマークスイープの併用 8
  • 9. JHCのGC● オブジェクトサイズとオブジェクト内に含むポインタ数による組をベース に、キャッシュラインを組んでいる。● GHCのInfoPointerを領域単位で取りまとめているというイメージでも可● 個々のキャッシュラインは実際にはブロックのリスト Size:4 Size:6 Ptrs:3 Ptrs:3 Size:4 Size:8 Ptrs:2 Ptrs:4 Size:4 Size:9 Ptrs:1 Ptrs:0 9
  • 10. JHCのGC● マークオンリーGCの動作 – GC開始時に使用中フラグを全部リセットする。 – Rootからたどっていって、使っているオブジェクトだけ 使用中フラグをマーク。● 以上で肝はほぼ全て終わり。● アロケーション時にキャッシュラインから一生懸命 空きを探します。 – 各ブロックの先頭にused bitarrayがある。 10
  • 11. JHCのGC● あれ?あれ? – Sweepはないの?ファイナライザは? ● ファイナライザは見切っています。 ● ファイナライザが必要な場合はマークスイープ側でアロケーション。 – フラグメントたまらない? ● BiBoP的方法を使って回避してます。 – アロケーションのコストかかるのでは? ● コスト下げるためのちょっとした工夫があります。(後述) – オブジェクトサイズ×ポインタ数ごとにキャッシュライン、ってメモ リ食い過ぎじゃね? ● う~ん、、、そんな気もする。詳しくはJohnさんへ。 11
  • 12. JHCのGC● アロケーション高速化の工夫 – bitmapを使ってるので、ビットマップが-1にならないのが空きブ ロックだ! – 同じキャッシュラインの中で優先度を多少入れ替える ● ブロックをバブルソートwww ● 空きの大きいものを優先的に前へ ● こうすればアロケーションの探索作業が減る(たぶん) Size:4 Ptrs:2 12
  • 13. JHCのGC● スタックまわり – C言語スタックとGCスタック – GCスタックはスタック上の変数コピーが取られている 実行スタック GCポインタ GCスタック GCスタックのてっぺん GCポインタ GCポインタ 13 GCスタックの底
  • 14. 本編 小二病でもGCやりたい~オレのかんがえたさいきょうGC~ 14
  • 15. オレのかんがえたさいきょうGC● JHCがカーネル内動作するために課された課題 – マルチスレッド化 ● たくさんの論理タスクを平行に走らせたい – ユーザーランド関連処理 – デバイス処理 – その他 – 応答性 ● Gcで100ms割り込み処理が止まるとかありえない – 省フットプリント ● よ~するに使用メモリは減らしておきたい ● 特に規模スケールした時の結果が重要かも – スループット ● う~ん、どうなんだろ、重要かな? 15
  • 16. 何を優先する?● Matzさんも言ってたけど● 応答性は重要 – これは多分間違いない● masterq_hentaiさんが言うには● スレッド対応 – 避けて通れないらしい● そうなると多分、● SMP – スレッドって言うからにはこれも多分。。。 16
  • 17. スレッド対応?● レベル1 – タイマーポーリングな論理タスクスイッチ ● スイッチポイントを持つスレッド切り替え● レベル2 – タイマー割り込みな論理タスクスイッチ ● 割り込みハンドラで強制的にタスク切り替え ● まずいところを割り禁で守るスタイル● レベル3 – SMPスレッド対応(いきなり飛んだな) ● スレッド間同期を意識した設計 ● キャッシュコヒーレンシとかも意識 17
  • 18. スレッド対応?● レベル1 – タイマーポーリングな論理タスクスイッチ ● スイッチポイントを持つスレッド切り替え● レベル2 – タイマー割り込みな論理タスクスイッチ ● 割り込みハンドラで強制的にタスク切り替え ● まずいところを割り禁等で守るスタイル● レベル3 この辺か。。。 – SMPスレッド対応(いきなり飛んだな) ● スレッド間同期を意識した設計 ● キャッシュコヒーレンシとかも意識 18
  • 19. 応答性能● 2つの応答性能 – 割り込み応答 ● 停止時間を短くする ● 優秀な面々 – コンカレント/インクリメンタルマークスイープが優秀 – リファレンスカウントなども ● 苦手な面々 – コピーGC、全停止マークスイープ ● 開放時、ファイナライザ処理がブロックしないようインプリメンタも気にする必要はある – 開放応答 ● 要らない領域を素早く開放するか、さもなくば全停止GC – メモリが開放されなければ応答できない時もある ● リファレンスカウントや明示的デストラクタが優秀 – エスケープ解析による明示的デストラクションとかも視野 19
  • 20. フットプリント● ブート初期 – 過去のローダーとの互換性を考えると重要● 起動後 – フットプリントにインパクトを与える要因 ● オブジェクト数とサイズプロファイル – 調査してないけど数も多くばらつきも多い – まー、少なかったらそれはそれで ● 解放によって発生したフラグメント ● 割り当てサイズの問題によるスキマ領域 – 2^nサイズでしか割り当てない場合など – Mozillaを悩ませた「ダークマター問題」 – よーするに、フラグメント/スキマを考慮できてればおkでは? 20
  • 21. さいきょうのGC● その1 – 参照カウント+インクリメンタルコンカレントマークスイープ ● 応答性の良い参照カウントで運用してサイクルだけをインクリメンタルスレッドにより開放する ● いいところ – 応答性がとてもいい ● 悪いところ – スループットがめっちゃ悪い – SMPになったら参照カウンタ同期の嵐 ● 検討点 – フラグメント対策 – スループット向上策● その2 – インクリメンタルマークスイープのみ ● いいところ – 出来上がり早そう – 応答性が結構いい ● 悪いところ – 開放性能が悪い ● 検討ポイント – フラグメント対策 – スループット向上作 どこが「さいきょう」かは読者の課題とする 21
  • 22. さいきょうのGC(まとめ)● 出て来なかった奴もいるが気にしない スレッド 応答性 フラグメント対策 スループットコピーGC ○ ✘ (mutator 全停 ◎ ◎+ 問題無さげ 止)マークスイープマークスイープ ○ △ 開放性能にリ BiBoPかな ○ 問題無さげ スクあり参照カウント △ ○ BiBoPかな △ 正直つらいか+ SMPで遅くなり もマークスイープ そう 22
  • 23. エピローグ 23
  • 24. 実は。。。。● しばらくJHCのコピーGC化の作業をしていた。● その中でちょっと困っていたこと 24
  • 25. ちょっとした恐怖● C言語が勝手に積んだ変数を拾うことはできな い。。。C言語が変数をマージしたりすると困る。。。 – コピーGCには死、あるのみ。 実行スタック GCポインタ GCスタック GCスタックのてっぺん GCポインタ GCポインタ 25
  • 26. 突然のC● 実は – JHCのGCはアロケーション時か明示的コールによってしか 発生しない ● つまり、カット点が明確● レベル2 – タイマー割り込みな論理タスクスイッチ ● 割り込みハンドラで強制的にタスク切り替え ● まずいところを割り禁等で守るスタイル● → ワーキングスレッド以外にとっては「突然のGC」 _人人 人人_ >突然のGC<  ̄ Y^Y^Y^Y ̄ 26
  • 27. あともうちょっとだけ● 検証したいこと – OS内でのメモリ割り当てのプロファイル ● 数とか、サイズとかの分布 – パフォーマンス – 割禁中にGCは許すか? – スループットの向上施策 – SMPを見据えたGC ● なんか組み込みCPU安くなってきちゃってさ… 27
  • 28. 最後に一言● 当日に言うな! 28