SlideShare uma empresa Scribd logo
1 de 28
小二病でもGCやりたい




              1
おやくそく
●   ID: dec9ue
●   属性:組み込みエンジニア
●   言語遍歴
    –   N88-BASIC ← 高校生: PC持ってなかった
    –   SMLNJ/OCaml ← 学生時代:大堀/雅利賀先生
    –   C++ ← 社会人
    –   Java ← プロジェクト変わった
    –   C ← 更にプロジェクト変更: お金を稼ぐ気になった
    –   Verilog ← HW開発部署になった、いまここ
メニュー
●   JHCのGC
●   本編
●   エピローグ




                    3
JHCのGC




         4
JHCのGC
●   GCにはいろいろあれど。。。


             明示的開放   オブジェクト 主な処理系
                     の移動
マークスイープGC    あり      なし     Java(コピーも併用)
                            Dalvik
                            Cruby
                            OCaml
参照カウント法      あり      なし     Cpython(MSも併用)
コピーGC        なし      あり     GHC RTS
                            Java(MSも併用)
マークコンパクトGC   実施可能    あり     Lisp2
                                             5
JHCのGC
●   たいていのGCは複数の機構を併用している
●
    基本的な理由
    –   GCの方式によって得意不得意がある
●   ありがちな要因
    –   パフォーマンス
        ●   割り当て機会が多い(割り当てコストの低いコピーGCl)
        ●   大きなオブジェクトはコピーに弱い(コピーしないマークスイープGC)
    –   ファイナライザが必要(参照カウンタ・マークスイープ)
        ●
            言語機構にファイナライザがある
        ●   FFIやリソースの開放処理を伴う場合


                                                6
JHCのGC
●   ありがちな2種類
●   Cpython
    –   参照カウント(コストが実行系側に集約される)
    –   マークスイープ(循環・オーバーフロー回収のため)
●   GHC
    –   コピー(割り当てが高速)
    –   マークスイープ(LargeObjectやFFIのため)



                                      7
JHCのGC
●   JHCのJGCはまた格別
●   いわば


       マークオンリーGC
●   とマークスイープの併用



                     8
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
JHCのGC
●   マークオンリーGCの動作
    –   GC開始時に使用中フラグを全部リセットする。
    –   Rootからたどっていって、使っているオブジェクトだけ
        使用中フラグをマーク。
●   以上で肝はほぼ全て終わり。
●   アロケーション時にキャッシュラインから一生懸命
    空きを探します。
    –   各ブロックの先頭にused bitarrayがある。


                                      10
JHCのGC
●
    あれ?あれ?
    –   Sweepはないの?ファイナライザは?
        ●
            ファイナライザは見切っています。
        ●
            ファイナライザが必要な場合はマークスイープ側でアロケーション。
    –   フラグメントたまらない?
        ●   BiBoP的方法を使って回避してます。
    –   アロケーションのコストかかるのでは?
        ●   コスト下げるためのちょっとした工夫があります。(後述)
    –   オブジェクトサイズ×ポインタ数ごとにキャッシュライン、ってメモ
        リ食い過ぎじゃね?
        ●   う~ん、、、そんな気もする。詳しくはJohnさんへ。


                                              11
JHCのGC
●
    アロケーション高速化の工夫
    –   bitmapを使ってるので、ビットマップが-1にならないのが空きブ
        ロックだ!
    –   同じキャッシュラインの中で優先度を多少入れ替える
         ●   ブロックをバブルソートwww
         ●
             空きの大きいものを優先的に前へ
         ●   こうすればアロケーションの探索作業が減る(たぶん)




        Size:4
        Ptrs:2



                                            12
JHCのGC
●   スタックまわり
    –   C言語スタックとGCスタック
    –   GCスタックはスタック上の変数コピーが取られている
        実行スタック
                 GCポインタ    GCスタック

                                      GCスタックのてっぺん


                  GCポインタ




                 GCポインタ




                                                    13
                                    GCスタックの底
本編
   小二病でもGCやりたい
~オレのかんがえたさいきょうGC~




                    14
オレのかんがえたさいきょうGC
●   JHCがカーネル内動作するために課された課題
    –   マルチスレッド化
        ●   たくさんの論理タスクを平行に走らせたい
            –   ユーザーランド関連処理
            –   デバイス処理
            –   その他
    –   応答性
        ●   Gcで100ms割り込み処理が止まるとかありえない
    –   省フットプリント
        ●   よ~するに使用メモリは減らしておきたい
        ●   特に規模スケールした時の結果が重要かも
    –   スループット
        ●   う~ん、どうなんだろ、重要かな?


                                        15
何を優先する?
●   Matzさんも言ってたけど
●
    応答性は重要
    –   これは多分間違いない
●   masterq_hentaiさんが言うには
●   スレッド対応
    –   避けて通れないらしい
●   そうなると多分、
●   SMP
    –   スレッドって言うからにはこれも多分。。。


                               16
スレッド対応?
●   レベル1
    –   タイマーポーリングな論理タスクスイッチ
        ●
            スイッチポイントを持つスレッド切り替え
●   レベル2
    –   タイマー割り込みな論理タスクスイッチ
        ●
            割り込みハンドラで強制的にタスク切り替え
        ●
            まずいところを割り禁で守るスタイル
●   レベル3
    –   SMPスレッド対応(いきなり飛んだな)
        ●
            スレッド間同期を意識した設計
        ●
            キャッシュコヒーレンシとかも意識


                                   17
スレッド対応?
●   レベル1
    –   タイマーポーリングな論理タスクスイッチ
        ●
            スイッチポイントを持つスレッド切り替え
●   レベル2
    –   タイマー割り込みな論理タスクスイッチ
        ●
            割り込みハンドラで強制的にタスク切り替え
        ●
            まずいところを割り禁等で守るスタイル
●   レベル3                          この辺か。。。

    –   SMPスレッド対応(いきなり飛んだな)
        ●
            スレッド間同期を意識した設計
        ●
            キャッシュコヒーレンシとかも意識


                                            18
応答性能
●   2つの応答性能
    –   割り込み応答
        ●
            停止時間を短くする
        ●
            優秀な面々
            –   コンカレント/インクリメンタルマークスイープが優秀
            –   リファレンスカウントなども
        ●
            苦手な面々
            –   コピーGC、全停止マークスイープ
        ●
            開放時、ファイナライザ処理がブロックしないようインプリメンタも気にする必要はある
    –   開放応答
        ●   要らない領域を素早く開放するか、さもなくば全停止GC
            –   メモリが開放されなければ応答できない時もある
        ●
            リファレンスカウントや明示的デストラクタが優秀
            –   エスケープ解析による明示的デストラクションとかも視野




                                                       19
フットプリント
●
    ブート初期
    –   過去のローダーとの互換性を考えると重要
●
    起動後
    –   フットプリントにインパクトを与える要因
        ●
            オブジェクト数とサイズプロファイル
            –   調査してないけど数も多くばらつきも多い
            –   まー、少なかったらそれはそれで
        ●
            解放によって発生したフラグメント
        ●
            割り当てサイズの問題によるスキマ領域
            –   2^nサイズでしか割り当てない場合など
            –   Mozillaを悩ませた「ダークマター問題」
    –   よーするに、フラグメント/スキマを考慮できてればおkでは?


                                         20
さいきょうのGC
●
    その1
    –   参照カウント+インクリメンタルコンカレントマークスイープ
        ●
            応答性の良い参照カウントで運用してサイクルだけをインクリメンタルスレッドにより開放する
        ●
            いいところ
            –   応答性がとてもいい
        ●
            悪いところ
            –   スループットがめっちゃ悪い
            –   SMPになったら参照カウンタ同期の嵐
        ●
            検討点
            –   フラグメント対策
            –   スループット向上策
●
    その2
    –   インクリメンタルマークスイープのみ
        ●
            いいところ
            –   出来上がり早そう
            –   応答性が結構いい
        ●
            悪いところ
            –   開放性能が悪い
        ●
            検討ポイント
            –   フラグメント対策
            –   スループット向上作


                            どこが「さいきょう」かは読者の課題とする
                                                          21
さいきょうのGC(まとめ)
●   出て来なかった奴もいるが気にしない

          スレッド       応答性             フラグメント対策   スループット


コピーGC     ○          ✘ (mutator 全停   ◎          ◎
+         問題無さげ      止)
マークスイープ
マークスイープ   ○          △ 開放性能にリ BiBoPかな           ○
          問題無さげ      スクあり

参照カウント    △          ○               BiBoPかな    △ 正直つらいか
+         SMPで遅くなり                              も
マークスイープ   そう



                                                           22
エピローグ




        23
実は。。。。
●   しばらくJHCのコピーGC化の作業をしていた。
●   その中でちょっと困っていたこと




                              24
ちょっとした恐怖
●   C言語が勝手に積んだ変数を拾うことはできな
    い。。。C言語が変数をマージしたりすると困る。。。
    –   コピーGCには死、あるのみ。
         実行スタック
                  GCポインタ    GCスタック

                                     GCスタックのてっぺん


                   GCポインタ




                  GCポインタ




                                                   25
突然のC
●
    実は
    –   JHCのGCはアロケーション時か明示的コールによってしか
        発生しない
        ●
            つまり、カット点が明確
●   レベル2
    –   タイマー割り込みな論理タスクスイッチ
        ●
            割り込みハンドラで強制的にタスク切り替え
        ●
            まずいところを割り禁等で守るスタイル
●   → ワーキングスレッド以外にとっては「突然のGC」
                    _人人 人人_
                    >突然のGC<
                     ̄ Y^Y^Y^Y ̄
                                       26
あともうちょっとだけ
●   検証したいこと
    –   OS内でのメモリ割り当てのプロファイル
        ●
            数とか、サイズとかの分布
    –   パフォーマンス
    –   割禁中にGCは許すか?
    –   スループットの向上施策
    –   SMPを見据えたGC
        ●   なんか組み込みCPU安くなってきちゃってさ…



                                     27
最後に一言
●   当日に言うな!




                      28

Mais conteúdo relacionado

Mais procurados

RcppEigen and SVD
RcppEigen and SVDRcppEigen and SVD
RcppEigen and SVDXiangze
 
カーネル VM懇親会LT
カーネル VM懇親会LTカーネル VM懇親会LT
カーネル VM懇親会LTcosmo0920
 
Google Perf Tools (tcmalloc) の使い方
Google Perf Tools (tcmalloc) の使い方Google Perf Tools (tcmalloc) の使い方
Google Perf Tools (tcmalloc) の使い方Kazuki Ohta
 
PyPy 紹介
PyPy 紹介PyPy 紹介
PyPy 紹介shoma h
 
Pythonista による Pythonista のための Scala 紹介 in BPStudy #49
Pythonista による Pythonista のための Scala 紹介 in BPStudy #49Pythonista による Pythonista のための Scala 紹介 in BPStudy #49
Pythonista による Pythonista のための Scala 紹介 in BPStudy #49shoma h
 
Vivado hlsのシミュレーションとhlsストリーム
Vivado hlsのシミュレーションとhlsストリームVivado hlsのシミュレーションとhlsストリーム
Vivado hlsのシミュレーションとhlsストリームmarsee101
 
Qt5 の新機能 2012/12/15
Qt5 の新機能 2012/12/15Qt5 の新機能 2012/12/15
Qt5 の新機能 2012/12/15Takumi Asaki
 
【関東GPGPU勉強会#3】OpenCVの新機能 UMatを先取りしよう
【関東GPGPU勉強会#3】OpenCVの新機能 UMatを先取りしよう【関東GPGPU勉強会#3】OpenCVの新機能 UMatを先取りしよう
【関東GPGPU勉強会#3】OpenCVの新機能 UMatを先取りしようYasuhiro Yoshimura
 

Mais procurados (9)

Qt小技(修正版)
Qt小技(修正版)Qt小技(修正版)
Qt小技(修正版)
 
RcppEigen and SVD
RcppEigen and SVDRcppEigen and SVD
RcppEigen and SVD
 
カーネル VM懇親会LT
カーネル VM懇親会LTカーネル VM懇親会LT
カーネル VM懇親会LT
 
Google Perf Tools (tcmalloc) の使い方
Google Perf Tools (tcmalloc) の使い方Google Perf Tools (tcmalloc) の使い方
Google Perf Tools (tcmalloc) の使い方
 
PyPy 紹介
PyPy 紹介PyPy 紹介
PyPy 紹介
 
Pythonista による Pythonista のための Scala 紹介 in BPStudy #49
Pythonista による Pythonista のための Scala 紹介 in BPStudy #49Pythonista による Pythonista のための Scala 紹介 in BPStudy #49
Pythonista による Pythonista のための Scala 紹介 in BPStudy #49
 
Vivado hlsのシミュレーションとhlsストリーム
Vivado hlsのシミュレーションとhlsストリームVivado hlsのシミュレーションとhlsストリーム
Vivado hlsのシミュレーションとhlsストリーム
 
Qt5 の新機能 2012/12/15
Qt5 の新機能 2012/12/15Qt5 の新機能 2012/12/15
Qt5 の新機能 2012/12/15
 
【関東GPGPU勉強会#3】OpenCVの新機能 UMatを先取りしよう
【関東GPGPU勉強会#3】OpenCVの新機能 UMatを先取りしよう【関東GPGPU勉強会#3】OpenCVの新機能 UMatを先取りしよう
【関東GPGPU勉強会#3】OpenCVの新機能 UMatを先取りしよう
 

Semelhante a 小二病でもGCやりたい

Deep learning実装の基礎と実践
Deep learning実装の基礎と実践Deep learning実装の基礎と実践
Deep learning実装の基礎と実践Seiya Tokui
 
Cgroupあれこれ-第4回コンテナ型仮想化の情報交換会資料
Cgroupあれこれ-第4回コンテナ型仮想化の情報交換会資料Cgroupあれこれ-第4回コンテナ型仮想化の情報交換会資料
Cgroupあれこれ-第4回コンテナ型仮想化の情報交換会資料KamezawaHiroyuki
 
あるRISC-V CPUの 浮動小数点数(異常なし)
あるRISC-V CPUの 浮動小数点数(異常なし)あるRISC-V CPUの 浮動小数点数(異常なし)
あるRISC-V CPUの 浮動小数点数(異常なし)たけおか しょうぞう
 
Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015
Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015
Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015CODE BLUE
 
[DL輪読会]Convolutional Sequence to Sequence Learning
[DL輪読会]Convolutional Sequence to Sequence Learning[DL輪読会]Convolutional Sequence to Sequence Learning
[DL輪読会]Convolutional Sequence to Sequence LearningDeep Learning JP
 
Concurrent Mark-Sweep Garbage Collection #jjug_ccc
Concurrent Mark-Sweep Garbage Collection #jjug_cccConcurrent Mark-Sweep Garbage Collection #jjug_ccc
Concurrent Mark-Sweep Garbage Collection #jjug_cccYuji Kubota
 
RubyのGC改善による私のエコライフ
RubyのGC改善による私のエコライフRubyのGC改善による私のエコライフ
RubyのGC改善による私のエコライフNarihiro Nakamura
 
大規模言語モデル開発を支える分散学習技術 - 東京工業大学横田理央研究室の藤井一喜さん
大規模言語モデル開発を支える分散学習技術 - 東京工業大学横田理央研究室の藤井一喜さん大規模言語モデル開発を支える分散学習技術 - 東京工業大学横田理央研究室の藤井一喜さん
大規模言語モデル開発を支える分散学習技術 - 東京工業大学横田理央研究室の藤井一喜さんAkira Shibata
 
色々なOSSで競技プログラミング
色々なOSSで競技プログラミング色々なOSSで競技プログラミング
色々なOSSで競技プログラミングnhirokinet
 
2012-03-08 MSS研究会
2012-03-08 MSS研究会2012-03-08 MSS研究会
2012-03-08 MSS研究会Kimikazu Kato
 
Code Reading at Security and Programming camp 2011
Code Reading at Security and Programming camp 2011 Code Reading at Security and Programming camp 2011
Code Reading at Security and Programming camp 2011 Hiro Yoshioka
 
不安定な環境の中でのバッチ処理~JobQueueシステムQudoを使った事例~
不安定な環境の中でのバッチ処理~JobQueueシステムQudoを使った事例~不安定な環境の中でのバッチ処理~JobQueueシステムQudoを使った事例~
不安定な環境の中でのバッチ処理~JobQueueシステムQudoを使った事例~Akabane Hiroyuki
 
【旧版】2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
【旧版】2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来【旧版】2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
【旧版】2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来Preferred Networks
 
2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来Preferred Networks
 
第11回 配信講義 計算科学技術特論B(2022)
第11回 配信講義 計算科学技術特論B(2022)第11回 配信講義 計算科学技術特論B(2022)
第11回 配信講義 計算科学技術特論B(2022)RCCSRENKEI
 
ICFP2009-いかにして我々は戦ったか
ICFP2009-いかにして我々は戦ったかICFP2009-いかにして我々は戦ったか
ICFP2009-いかにして我々は戦ったかina job
 
Programming camp 2010 debug hacks
Programming camp 2010 debug hacksProgramming camp 2010 debug hacks
Programming camp 2010 debug hacksHiro Yoshioka
 
BMS Molecular Translation 3rd place solution
BMS Molecular Translation 3rd place solutionBMS Molecular Translation 3rd place solution
BMS Molecular Translation 3rd place solutionKazuki Fujikawa
 

Semelhante a 小二病でもGCやりたい (20)

Deep learning実装の基礎と実践
Deep learning実装の基礎と実践Deep learning実装の基礎と実践
Deep learning実装の基礎と実践
 
Cgroupあれこれ-第4回コンテナ型仮想化の情報交換会資料
Cgroupあれこれ-第4回コンテナ型仮想化の情報交換会資料Cgroupあれこれ-第4回コンテナ型仮想化の情報交換会資料
Cgroupあれこれ-第4回コンテナ型仮想化の情報交換会資料
 
Math works gdlc2019
Math works gdlc2019Math works gdlc2019
Math works gdlc2019
 
あるRISC-V CPUの 浮動小数点数(異常なし)
あるRISC-V CPUの 浮動小数点数(異常なし)あるRISC-V CPUの 浮動小数点数(異常なし)
あるRISC-V CPUの 浮動小数点数(異常なし)
 
Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015
Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015
Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015
 
[DL輪読会]Convolutional Sequence to Sequence Learning
[DL輪読会]Convolutional Sequence to Sequence Learning[DL輪読会]Convolutional Sequence to Sequence Learning
[DL輪読会]Convolutional Sequence to Sequence Learning
 
Concurrent Mark-Sweep Garbage Collection #jjug_ccc
Concurrent Mark-Sweep Garbage Collection #jjug_cccConcurrent Mark-Sweep Garbage Collection #jjug_ccc
Concurrent Mark-Sweep Garbage Collection #jjug_ccc
 
Interrupt jhc
Interrupt jhcInterrupt jhc
Interrupt jhc
 
RubyのGC改善による私のエコライフ
RubyのGC改善による私のエコライフRubyのGC改善による私のエコライフ
RubyのGC改善による私のエコライフ
 
大規模言語モデル開発を支える分散学習技術 - 東京工業大学横田理央研究室の藤井一喜さん
大規模言語モデル開発を支える分散学習技術 - 東京工業大学横田理央研究室の藤井一喜さん大規模言語モデル開発を支える分散学習技術 - 東京工業大学横田理央研究室の藤井一喜さん
大規模言語モデル開発を支える分散学習技術 - 東京工業大学横田理央研究室の藤井一喜さん
 
色々なOSSで競技プログラミング
色々なOSSで競技プログラミング色々なOSSで競技プログラミング
色々なOSSで競技プログラミング
 
2012-03-08 MSS研究会
2012-03-08 MSS研究会2012-03-08 MSS研究会
2012-03-08 MSS研究会
 
Code Reading at Security and Programming camp 2011
Code Reading at Security and Programming camp 2011 Code Reading at Security and Programming camp 2011
Code Reading at Security and Programming camp 2011
 
不安定な環境の中でのバッチ処理~JobQueueシステムQudoを使った事例~
不安定な環境の中でのバッチ処理~JobQueueシステムQudoを使った事例~不安定な環境の中でのバッチ処理~JobQueueシステムQudoを使った事例~
不安定な環境の中でのバッチ処理~JobQueueシステムQudoを使った事例~
 
【旧版】2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
【旧版】2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来【旧版】2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
【旧版】2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
 
2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
2009/12/10 GPUコンピューティングの現状とスーパーコンピューティングの未来
 
第11回 配信講義 計算科学技術特論B(2022)
第11回 配信講義 計算科学技術特論B(2022)第11回 配信講義 計算科学技術特論B(2022)
第11回 配信講義 計算科学技術特論B(2022)
 
ICFP2009-いかにして我々は戦ったか
ICFP2009-いかにして我々は戦ったかICFP2009-いかにして我々は戦ったか
ICFP2009-いかにして我々は戦ったか
 
Programming camp 2010 debug hacks
Programming camp 2010 debug hacksProgramming camp 2010 debug hacks
Programming camp 2010 debug hacks
 
BMS Molecular Translation 3rd place solution
BMS Molecular Translation 3rd place solutionBMS Molecular Translation 3rd place solution
BMS Molecular Translation 3rd place solution
 

小二病でもGCやりたい

  • 2. おやくそく ● ID: dec9ue ● 属性:組み込みエンジニア ● 言語遍歴 – N88-BASIC ← 高校生: PC持ってなかった – SMLNJ/OCaml ← 学生時代:大堀/雅利賀先生 – C++ ← 社会人 – Java ← プロジェクト変わった – C ← 更にプロジェクト変更: お金を稼ぐ気になった – Verilog ← HW開発部署になった、いまここ
  • 3. メニュー ● JHCのGC ● 本編 ● エピローグ 3
  • 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
  • 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