2023/2/6
Ruby Association Grant Targets
Developing Pf2
✅ Simultaneous observation of multiple Ruby Threads
✅ Improved visualization
✅ Automated testing
✅ GVL observation
✅ When did the Thread acquire the lock?
Contention information
How long are Threads waiting for the lock?
GC observation
✅ Markers
今回の進捗
やった
pf2 0.3.0 をリリース
libbacktrace を使った native stack consolidation をマージ
まともな設定インタフェースができた
code:quickstart.rb
Pf2.start(interval_ms: 10, time_mode: :cpu)
do_something
profile = Pf2.stop
code:full.rb
profiler = Pf2::SignalScheduler.new(interval_ms: 10, time_mode: :cpu, track_new_threads: true)
profiler.start
do_something
profile = profiler.stop
RubyKaigi にプロポーザルを出した
ちゃんと話すことがあるように頑張らないと……
あと13週間らしい
やってる・やっていく
スタックの中間の cfunc の部分への native frame の挿入
---
雑談
profile_frames() と backtrace_each() の結果が完全に一致してほしい
main thread だけ最後に <main> が入る
profile_frames() が struct を返すことはできない?
free できないから厳しい?
そもそも iseq は GC の対象だから iseq を返す限りは VALUE が妥当
デザインとして iseq を返す限りは void * よりも VALUE のほうが便利そう
rb_profile_thread_frames() にすでに停止した VALUE thread を渡したら 0 を返すとかしてほしい
やるだけ?
Grant をどこにもっていこうかな
= 中心的な成果をどこに持っていく?
終わりがある
C のスタックを出せること
Firefox Profiler による visualization
GC, GVL の様子を見られるようにした
やったこととしては gvltools, gvl-tracing とそんなに変わらない気はする
あともう一つできそうなことの idea
Streaming
C のスタックのところ
競合がいないところで勝負するのが良いかも
今は C を Ruby にマージしてるけど、逆の方が楽なイメージはあるか? → ロジックは変わらないのでなさそう
ubuntu のバージョンを上げたときに mysql2 が遅くなったが
Stackprof では原因を特定できなかった
perf を使って追う…… みたいなことをしたので、use case は確実にある
rb_get_kwargs() むずい……
2024年3月20日 最終報告の提出期限
↑ これはレポート
これとは別に presentation があったはず