技術部で Ruby インタプリタの開発をしている笹田です。娘のために、今年はじめて大きなクリスマスツリー（1.8 m）を買いました。
本稿では、私が Ruby 2.6 で取り組んだ中から、次の新しい機能と性能改善について紹介します。どちらのトピックも、普通に Ruby を使っているだけなら気にならない、玄人向きの記事になっていると思います。興味がある人にお読み頂ければ幸いです（居ればいいのですが）。
- TracePoint の拡張
- 新しいイベント script_compiled の導入
- フックを有効にする場所を制限する機能の導入
- デバッガの実装が、10～100倍くらい速くなる、かもしれない
- ブレイクポイントの実装を例に解説
- Transient Heap の導入
- 短寿命メモリオブジェクトの高速化
- 世代別コピーGCのアイディアを利用
- Rails とかには効かないかも...。
そういえば、両方とも "Tra"で始まってますね。寅年はまだ先ですが。
本稿は、Cookpad techlife で三日連続で掲載する Ruby 2.6 紹介記事の最後になります。
タイトルは 昨年の記事 Ruby 2.5 の改善を自慢したいの二番煎じです。来年もやるのかな...。
目次
TracePoint の拡張
まず、簡単なほう、TracePoint の拡張の話から始めます。
TracePoint 基礎
TracePoint は、プログラム中のイベントで起動する Proc を登録するための仕組みです。イベントには、毎行ごとに実行する line イベントや、メソッドの呼び出しと、そのリターンごとに実行する call、return などがあります。
例えば、すべてのメソッド呼び出し、およびそのリターンをログに出力したい、というプログラムは次のように簡単に書くことができます。
1deffoo; bar; end2defbar; nil; end34TracePoint.trace(:call, :return){|tp| p tp} 56 foo
このプログラムを実行すると、次のような出力が得られます。
#<TracePoint:call `foo'@t.rb:1> #<TracePoint:call `bar'@t.rb:2> #<TracePoint:return `bar'@t.rb:2> #<TracePoint:return `foo'@t.rb:1>
foo が呼ばれ、bar が呼ばれ、bar から戻り、foo から戻る、ということが見て取れます。が、ちょっと出力が読みづらいですね。呼び出しレベルごとにインデントを付けるようにしてみましょう。
indent = 0TracePoint.trace(:call, :return){|tp| indent -= 2if tp.event == :return print '' * indent; p tp indent += 2if tp.event == :call }
実行結果:
#<TracePoint:call `foo'@t.rb:1> #<TracePoint:call `bar'@t.rb:2> #<TracePoint:return `bar'@t.rb:2> #<TracePoint:return `foo'@t.rb:1>
ちょっと読みやすくなりました。もうちょっと整形してみましょう。
indent = 0TracePoint.trace(:call){|tp| puts "#{'' * indent}-> #{tp.method_id}@#{tp.path}:#{tp.lineno}" indent += 2 } TracePoint.trace(:return){|tp| indent -= 2 puts "#{'' * indent}<- #{tp.method_id}@#{tp.path}:#{tp.lineno}" }
TracePoint の設定を、call と return の2つに分けてみました。実行結果です。
-> foo@t.rb:1 -> bar@t.rb:2 <- bar@t.rb:2 <- foo@t.rb:1
どうでしょう。それっぽくなったでしょうか。
実は、TracePoint.trace(events){...}は TracePoint.new(events){...}.enable（新しい TracePoint を作成し、それを有効にする、という意味）の略なので、今後は TracePoint#enableを使うようにしてみます。
TracePoint の基礎はだいたいこんなものですが、詳細はるりまのドキュメント "class TracePoint (Ruby 2.5.0)"をご覧下さい。
TracePoint の問題
便利に、悪巧みに、色々使えそうな TracePoint ですが、性能の問題があります。
性能が気になる一番顕著な例はブレイクポイントの実装です。あるファイルのある行で実行を止める、ということを考えてみましょう。breakpoint('t.rb', 10)とすると、t.rb:10 で irb が起動するなんてどうでしょうか。
TracePoint を使うと、こんな感じで簡単に作ることができます。
defbreakpoint file, line TracePoint.new(:line){|tp| if tp.path == file && tp.lineno == line tp.binding.irb end }.enable end
各行で実行するフック（line イベントによるフック）中で、if tp.path == file && tp.lineno == lineという if 文で、指定された場所かどうかを判断し、もしそうであれば irb を実行します。Ruby 2.5 から binding.irbという便利なメソッドが追加されたので、もし指定された行を実行したら binding.irbを呼ぶようにしてみました。
では、早速使ってみましょう。
deffoo a, b p a, b # line 11end breakpoint __FILE__, 11 foo 10, 20 foo 30, 40
foo メソッドの1行目の pが11行目だったと思ってください。
実行結果：
From: /home/ko1/src/ruby/trunk/test.rb @ line 11 :
6: end
7: }.enable
8: end
9:
10: def foo a, b
=> 11: p a, b # line 11
12: end
13:
14: breakpoint __FILE__, 11
15:
16: foo(10, 20)
irb(main):001:0> p [a, b]
[10, 20]
=> [10, 20]
irb(main):002:0> exit
10
20
From: /home/ko1/src/ruby/trunk/test.rb @ line 11 :
6: end
7: }.enable
8: end
9:
10: def foo a, b
=> 11: p a, b # line 11
12: end
13:
14: breakpoint __FILE__, 11
15:
16: foo(10, 20)
irb(main):001:0> p [a, b]
[30, 40]
=> [30, 40]
irb(main):002:0>
30
40見事にブレイクポイントを持つデバッガっぽいものが出来ました！ たった数行（7行）でデバッガっぽいものが作れる Ruby って凄いですね！ ちなみに、byebug などどの Ruby 用デバッガも、基本的にこんな感じで実装されています。
ただ、性能に問題があります。この簡単なブレイクポイントの設置場所「とは関係ない」コードの実行時間を測ってみます。
deffib n case n when0, 1; n else fib(n-1) + fib(n-2) endendrequire'benchmark'Benchmark.bm{|x| x.report{ fib(30) } x.report{ breakpoint __FILE__, 11# enable breakpoint here fib(30) } }
user system total real 0.095480 0.000000 0.095480 ( 0.095490) 0.904503 0.000000 0.904503 ( 0.904552)
上が breakpoint なし、下が breakpoint ありです。実に 9.5 倍くらい遅くなっているのがわかります。実行している全ての行で上記（無駄な）チェックを行っているので、しょうがないといえばしょうがないかもしれません。
ちなみに byebug を使って、byebug のブレイクポイント機能を有効にした状態で fib(30)を実行してみましょう。
$ byebug /home/ko1/src/ruby/trunk/test.rb
...
(byebug) b 11
Created breakpoint 1 at /home/ko1/src/ruby/trunk/test.rb:11
(byebug)
user system total real
7.406062 0.000000 7.406062 ( 7.406415)さらに遅いです。何もしない場合に比べ、80倍程度遅いようです。きっと、他にもいろいろな処理をしているんでしょうね。
今回はブレイクポイントを例にしましたが、最初に紹介したメソッド呼び出し履歴のロギングでも、例えば gem は除く、といった要望は当然出てくると思います。
TracePoint#enable(target:, target_line:)拡張
さて、TracePoint では無駄なフックを呼んでしまうことで性能上問題が生じる、ということをご紹介しました。10倍とか100倍遅くなってしまいました。なんとかしたい。
そこで、Ruby 2.6 では、TracePoint を有効にする場所を制限するという拡張を TracePoint#enableメソッドに行うことにしました。
enable(target: code, target_line: line) と、target:と target_line:キーワードを追加しました。これらのキーワードを利用することで、指定された code および行番号に、イベント発火を絞ることができます。
なお、target_line:は lineイベントにだけ有効です。そのため、lineイベントと一緒に、他のイベント（callなど）が指定されていると、target_line:を指定していても、callなどは有効になります。わかりやすいように、target_line:指定は lineイベントのみと一緒に使うことをオススメします。
さて、この拡張を用いて、実際にちゃんと動くブレイクポイントを作ることができるか試してみましょう。まず、breakpoint メソッドの仕様を変更します。
defbreakpoint method, line TracePoint.new(:line){|tp| tp.binding.irb }.enable(target: method, targe_line: line) end
breakpointメソッドの第一引数がファイルではなく、method とあるのに注意してください。ここでは、メソッドオブジェクトを渡します。
使ってみましょう。
deffoo a, b p a, b # line 11end breakpoint method(:foo), 11 foo(10, 20) foo(30, 40)
実行結果です。
From: /home/ko1/src/ruby/trunk/test.rb @ line 11 :
6: tp.binding.irb
7: }.enable(target: method, target_line: line)
8: end
9:
10: def foo a, b
=> 11: p a, b # line 11
12: end
13:
14: breakpoint method(:foo), 11
15: foo(10, 20)
16: foo(30, 40)
irb(main):001:0> p [a, b]
[10, 20]
=> [10, 20]
irb(main):002:0> exit
10
20
From: /home/ko1/src/ruby/trunk/test.rb @ line 11 :
6: tp.binding.irb
7: }.enable(target: method, target_line: line)
8: end
9:
10: def foo a, b
=> 11: p a, b # line 11
12: end
13:
14: breakpoint method(:foo), 11
15: foo(10, 20)
16: foo(30, 40)
irb(main):001:0> p [a, b]
[30, 40]
=> [30, 40]
irb(main):002:0> exit
30
40先ほどと同様、ちゃんと動いていることが確認できました。
では、性能はどうなっているでしょうか。
user system total real 0.096092 0.000000 0.096092 ( 0.096180) 0.095210 0.000000 0.095210 ( 0.095306)
上が breakpoint なし、下が breakpoint ありです。ほぼ、実行時間に変わりが無いことがわかるかと思います。やった！
TracePoint#enable(target: code)の codeって何？
いやいや、ちょっと待って。いちいちメソッドオブジェクトを渡すのって大変じゃないですか。breakpoint(path, line)を実装したかったらどうすればいいんでしょうか。
そもそも、target: codeで指定する code とは、なんでしょうか？
ここには、Ruby で記述したプログラムにおける Method、UnboundMethod、Procおよび RubyVM::InstructionSequence（長いので、以降 ISeq）が指定できます。何やら難しそう...。そもそも、最後の ISeq って何。
Ruby で記述されたプログラムはバイトコードにコンパイルされます。そのバイトコードのことを Ruby (MRI) の文脈では命令列、Instruction Sequence、つまり ISeq と言ってます。
Ruby で記述したメソッドから取り出した Methodオブジェクトなどは、たどっていくと ISeq が取り出せます。実は、code で指定しているのは、ISeq なのです。
ちなみに、RubyVM::InstructionSequence.of(code)で、Methodや Procオブジェクトなどから ISeq が取り出せます。C で実装されたメソッドの場合、nilが返ります。TracePoint#enable(target: code)では、内部でまさに ISeq.of(code)を呼んで、ISeq を取り出しています。もし、ISeq が取り出せない場合はエラーになります。
p RubyVM::InstructionSequence.of(method(:p)) #=> nilTracePoint.new{}.enable(target: method(:p)) #=> <internal:prelude>:137:in `__enable': specified target is not supported (ArgumentError)
今回の拡張は、ある ISeq（および、その ISeq から辿ることができるすべての ISeq）に TracePoint を限定する、というのが正しい理解です。
例えば、aliasを使うとメソッドを増やすことができますが、指し示す ISeq は同じものです。
deffoo; endaliasbarfooISeq = RubyVM::InstructionSequence p ISeq.of(method(:foo)) == ISeq.of(method(:bar)) #=> true
そのため、enable(code: method(:bar))とすると、fooと barで有効な TracePoint になります。
同じように、ある Module を includeしたクラス C1, C2 も、同じメソッドを共有することになります。
moduleM; deffoo; end; endclassC1; includeM; endclassC2; includeM; endISeq = RubyVM::InstructionSequence p ISeq.of(C1.new.method(:foo)) == ISeq.of(C2.new.method(:foo)) #=> true
モジュールの例は、もしかしたらはまりやすいかもしれませんね。「そこからたどれるソースコードにイベントで発火する hook を登録する」という機能であることを抑えておくことが大事です。
メソッドを指定するブレイクポイント
メソッドを指定するブレイクポイントを実装する場合を考えます。あるメソッドが起動したとき、というタイミングにブレイクポイントを指定する場合ですね。
前節で実装した breakpointが、そのまま使えそうです。
defmethod_breakpoint method, line = nilTracePoint.new(:call){|tp| tp.binding.irb }.enable(target: method) end
「メソッドが呼ばれるとき」なので、callイベントのみを利用しています。target_line:指定がないことに気を付けてください。lineイベントがないのに target_line:指定があると、target_line is specified, but line event is not specified (ArgumentError)と怒られます。
簡単ですね。
C で実装されたメソッドの場合は、この方法ではうまくいきません。その点がちょっと残念ですね（これまで通り、c_callイベントをフックするか、Ruby でラッパーメソッドを書く、という方法があります。今だと後者が速いかな）。
場所を指定するブレイクポイント
さて、ファイル（path）と行（line）で場所を指定したいブレイクポイントを実装する場合、対象となる ISeq をどうやって集めてくるか、という問題になります。
実は、今の MRI には、そのための方法がないので、今回は外部の gem を使います。iseq_collectorです。この gem が提供する ObjectSpace.each_iseqは、インタプリタ中に存在するすべての ISeq を辿るという API です。
ISeq には ISeq#pathというメソッドがあり、そのメソッドが定義されたファイル名を知ることができるので、これで pathと比較することで、必要な ISeq を絞ることができます。
次に、lineの絞り方です。これには2通りのやり方があります。
まず、ISeq#trace_pointsを用いて指定の行があるかどうかを調べる方法です。
1deffoo2 p 13end45ISeq = RubyVM::InstructionSequence# 長いので6 pp ISeq.of(method(:foo)).trace_points #=> [[1, :call], [2, :line], [3, :return]]
結果を見るとわかりやすいと思いますが、1行目に call イベント、2行目に line イベント、3 行目に return イベント、計 3 イベントがfooメソッド（を実装する ISeq）に登録可能である、ということを示しています。
場所を指定するので、line イベントを利用します。このメソッドでは、2 行目のみ、場所指定のブレイクポイントをしかけることができる、と捉えることができます（call, return イベントを利用すれば、もうちょっと頑張れますが、ここでは触れません）。
もう一つの絞り方ですが、ちょっと乱暴に、とにかく pathで絞って得られた ISeq を用いて enable(target: iseq, target_line: line)を指定してしまう、というものです。もし、対象 ISeq に target_line:で指定した行がなければ、例外を返します。
12deffoo3 p 14end56TracePoint.new(:line){}.enable(target: method(:foo), target_line: 100) #=> <internal:prelude>:137:in `__enable': can not enable any hooks (ArgumentError)
100行目が見つからなかったので、「フックがどこにも指定できなかった」という例外を出しています。これを利用すれば、とにかく TracePoint#enableをしまくってみると、いつかはヒットするかも、という戦略が取れます。
今回は、前者、ISeq#trace_pointsを利用する方法を用いて、場所指定のブレイクポイントを設定するメソッドである location_breakpointを作ってみましょう。
1require'iseq_collector'2deflocation_breakpoint path, line 3ObjectSpace.each_iseq{|iseq| 4if iseq.path == path && 5 iseq.trace_points.find{|(l, ev)| l == line && ev == :line} 6TracePoint.new(:line){|tp| 7 tp.binding.irb 8 }.enable(target: iseq, target_line: line) 9 end 10 } 11end1213deffoo a, b 14 p a, b # line 1415end1617 location_breakpoint __FILE__, 1418 foo(10, 20) 19 foo(30, 40)
実際に動かしてみると、きちんと動いていることがわかると思います。やりました！
さて、ご紹介した2つ、method_breakpointおよび location_breakpointですが、1つ大きな問題があります。それは、「すでに requireなどでロードしているプログラムにしか適用できない」です。
デバッガの通常の利用方法として、「プログラムのある場所にブレイクポイントを指定する。そして、実行を開始する」というものがあります。一度、すべてのプログラムをロードしたどこかのタイミングでブレイクポイントを（これまで作成してきたメソッドを利用して）設定する、ということをしてもいいですが、Ruby の場合、この「すべてのプログラムをロードしたどこかのタイミング」を特定するのは困難です。dynamic reloading などをしていると、そもそもそういうタイミングがありません。
この問題を解決するのが、Ruby 2.6 から導入された新しいイベントである script_compiled です。
script_compiled によるコンパイル後の処理
Ruby 2.6 から、script_compiled イベントが新しく追加されました。
MRI は Ruby スクリプトを実行するために、
- (1) スクリプトをパースして AST（構文木）を作成
- (2) AST を ISeq に変換
- (3) ISeq を実行
という手順を踏んで実行します。 script_compiled イベントは、(2) 終了時に挿入されるフックです。
この機能を使うと、例えば、どんなファイルが requireや loadで実行されるか、実行直前で知ることができます。
コンパイルされ、生成された ISeq は TracePoint#instruction_sequenceメソッドで取得することができます。
では試しに、net/httpライブラリを requireすると、何が起こるのか、観察してみましょう。
TracePoint.new(:script_compiled){|tp| pp ["#{tp.path}:#{tp.lineno}", tp.instruction_sequence.path] }.enable require'net/http'
このプログラムでは、Ruby スクリプトを ISeq に変換したとき、「ロードしたソースコードの位置」、「ロードされたファイル名」を指定します。
["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:23", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/protocol.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/socket.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/timeout.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1645", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/exceptions.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1647", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/header.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1649", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/generic_request.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1650", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/request.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1651", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/requests.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1653", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/response.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1654", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/responses.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1656", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/proxy_delta.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http.rb:1658", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/net/http/backward.rb"]
このように、多くのファイルがロードされていることがわかります。
また、同じことを fileutilsで試してみます。
["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils/version.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb:1670", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb"] ... ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb:1670", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb:1695", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb"] ... ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb:1695", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb:1721", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb"] ... ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb:1721", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb"]
なぜか、同じ場所で沢山のプログラムがロードされているようです。ちょっとソースコードを確認してみましょう。
1669 names.each do |name| 1670module_eval(<<-EOS, __FILE__, __LINE__ + 1) 1671 def #{name}(*args, **options) 1672 super(*args, **options, verbose: true) 1673 end 1674 EOS 1675 end 1676 private(*names)
module_eavlがある部分です。eval(str)（module_eval(str), instance_eval(str)なども同様です）も requireなどと同様に、スクリプト srcを ISeq に変換して実行するので、script_compiled イベントでフックできるのです。
Ruby 2.6 からは、evalに渡した文字列を取得する TracePoint#eval_stringというメソッドがあります。これを利用することで、どんな文字列を evalで実行しているかがわかります。なお、requireなどファイル指定でファイルをロードした場合はこのメソッドは nilを返します。
では、試してみましょう。
TracePoint.new(:script_compiled){|tp| pp ["#{tp.path}:#{tp.lineno}", tp.instruction_sequence.path, tp.eval_script] }.enable require'fileutils'
結果はこんな感じです。
["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb", nil] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils/version.rb", nil] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb:1670", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb", " def cd(*args, **options)\n" + " super(*args, **options, verbose: true)\n" + " end\n"] ["/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb:1670", "/home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb", " def mkpath(*args, **options)\n" + " super(*args, **options, verbose: true)\n" + " end\n"] ...
module_evalによって何が実行されようとしているかがよくわかりますね。
さて、これらの機能を使うと、スクリプトがロードされた瞬間にブレイクポイントを仕込む、ということが可能になります。
では、これまでの知識を利用して、reserve_location_breakpoint path_pattern, lineというメソッドを作ってみましょう。パスを指定するパラメータ名が pathではなく path_patternなのは、パス名は Regexpでパターンマッチ出来た方が便利かなと思ったためです。
require'iseq_collector'deflocation_breakpoint path, line ObjectSpace.each_iseq{|iseq| if iseq.path == path && iseq.trace_points.find{|(l, ev)| l == line && ev == :line} TracePoint.new(:line){|tp| tp.binding.irb }.enable(target: iseq, target_line: line) end } enddefreserve_location_breakpoint path_pattern, line TracePoint.new(:script_compiled){|tp| compiled_script_path = tp.instruction_sequence.path if path_pattern =~ compiled_script_path location_breakpoint(compiled_script_path, line) end }.enable end reserve_location_breakpoint(/lib\/ruby\/2.6.0\/fileutils\.rb/, 9) # ロードするrequire'fileutils'
実行結果です。
From: /home/ko1/ruby/install/trunk/lib/ruby/2.6.0/fileutils.rb @ line 9 :
4: require 'rbconfig'
5: rescue LoadError
6: # for make mjit-headers
7: end
8:
=> 9: require "fileutils/version"
10:
11: #
12: # = fileutils.rb
13: #
14: # Copyright (c) 2000-2007 Minero Aoki
irb(main):001:0> exitちゃんと、これからロードするファイルに対してブレイクポイントを設定できました。
あと少し整備すれば、デバッガなんて簡単に作れそうですね！ やってみたくありませんか？
（場所指定ブレイクポイントは、だいたいこれでいいとして（出来た！）、ではメソッド指定ってどうやりますかね。こちらは、実はなかなか難しいけど、さすがに長くなりすぎるので省略します）
TracePoint#enable(target:)の背景と実装
さて、ここまでの記事は、Ruby 2.6 で導入された新しい TracePoint の拡張を用いて、デバッガのブレイクポイントをどうやって作るのか、ということを題材に、使い方をご紹介しました。これくらいの記事なら、ちょっと気の利いた人なら書けそうです。
本稿では差別化を図るために、これをどうやって実装したか、その背景とテクニックをご紹介します。これはさすがに私しか書けないでしょう。「筆者はこのとき何を考えていたか答えなさい」ってやつですね。
この拡張を導入した背景
TracePoint#enable(taget:)なんですが、ずっと導入したかった機能でした。それこそ、TracePoint 導入した Ruby 2.0 から。しかし、なかなか API が決められなかったんですよね。いろいろ考えちゃって、あーでもない、こーでもないと悩んで、時間がかかりました。欲しいって言う人も居ないし。今回、入った原因は2つ、外圧と割り切りでした。
まず、外圧ですが、背景として、RUBY_EVENT_SPECIFIED_LINEという隠し機能が、たしか Ruby 2.1 だかそこらで入れてありました。まさに、ブレイクポイントを実装するための仕組みです。が、Ruby 2.5 で命令書き換えによる trace prefix 命令への置換へ舵を切ったタイミング（詳細は Ruby 2.5 の改善を自慢したい）で、削除したんですよね。同じことは、選択的に命令書き換えすれば出来るだろう、って。
ただ、そのインターフェースを用意していなかった。正確には、用意をしていたんだけど、使おうとするととても使いづらかった。で、RUBY_EVENT_SPECIFIED_LINEなんて隠し機能で誰も知らないだろうおと思っていたら、JetBrain でデバッガを作るために使っていたそうなんですよね。で、復活させろー、というリクエストが来まして。ただ、今更戻すのは、いろいろな理由で良くない、ということで、本腰を入れて考え始めました。
割り切りは、ある TracePoint オブジェクトに対して、1 target しか指定できないようにしたことです。いろいろ考えていたときは、複数箇所をどのように対応させるか、それを指定するインターフェースはどうするべきか、というのが悩みどころだったんですが、もう単純に 1 TracePoint object ごとに 1 target、増減はしない！ と決めるとすんなり API が決まりました。
この拡張の技術的要点
ISeq ごとに、有効にする hooks を持たせた、というのがキモです。target:で指定された ISeq に、必要な命令を trace_ prefix 命令に変換しておきます。
target_line:指定があったときは、該当する行の命令のみ、trace_ prefix 命令に置き換えています。ただし、global に有効になる TracePoint と conflict すると、登録していないのに発火する hook を作ることが出来てしまうので、line で内部的にフィルタする仕組みを導入しました。
この辺はソースコードをちゃんと説明しないとわかりづらいので、雰囲気だけ、お伝えしました。
まとめ：TracePoint の拡張
TracePoint の拡張の話をちょっと説明しようと思ったら、Ruby でどうやってデバッガのブレイクポイントを実装するか、という説明になってしまいました。お楽しみ頂けたでしょうか。デバッガ作りたくなってきませんか？ 私はなりました。
TracePoint は、デバッガを作る以外にも、いくつか使いようがあります。
例えば、今回導入された script_compiled イベントを用いると、実際にどこでソースコードがロードされたかがわかります。特に、evalの利用を検知することができます。大規模プロジェクトで、なぜか良くわからない挙動をする、「もしかしたらどっかで意図しない evalがあるかも？」といったときに、こっそり含まれていた evalを検出する、などといった応用ができるかもしれません。
なお、幸いなことに、script_compiled イベントでは、コンパイル結果の ISeq を差し替えることはできません。平和は保たれました。
用法用量を守って、楽しくお使い頂ければと思います。
Ruby 2.6 で入れようと検討していて、時間切れで入らなかった機能が、沢山あるのですが、その中でも下記の 2 つについては、Ruby 2.7 で、可能なら入れたいと思っています。欲しい人、一緒に検討しませんか？
- caller/callee での call/return イベント
- 現状、call/return イベントは、caller で止まるのか callee で止まるのか、決まっていません（call/return は callee、c_call/c_return は caller）。どちらも明確に用意したいと思っています。
- その際、渡すパラメータ一覧なんかが取れると良さそうだと思っています。
- method_defined など、メソッド定義等などの変更をフックするイベント
長くなりましたが、TracePoint の拡張については、この辺で終わりにします。
Transient Heap (theap) の導入
もう誰もここまで読んでいない気がしますが、もう少しだけ続けます。
Ruby 2.6 では、Transient Heap (theap) という、メモリ管理のための新しい仕組みを導入しました。Ruby のメモリ管理が、また複雑になりました。
theap を大雑把に紹介すると、世代別コピーGCのテクニックを使うことで、対応済みのオブジェクトについて、短寿命なオブジェクトのために確保されたメモリを効率よく管理する仕組みを導入した、というものです。Array、Object（ユーザー定義クラス）、Struct、および 8 要素以下の Hash が theap を利用しています。
本章では、この theap について、かいつまんで介します。
なお、ここからは C のコードばかりになります。
現在のメモリ管理
Ruby でメモリ管理というとガーベージコレクタ（GC）を思い浮かべると思います。メモリ領域（とか、リソース）は GC によって寿命が管理されているので、やはり GC は花形です。昔の Ruby は遅い、と言われていましたが（今も、利用分野によっては言われていると思います）、GC の性能に問題があったことが、その理由の1つであったかと思います。
今（Ruby 2.2 以降）は、世代別インクリメンタル GC を実装しているので、あまり GC アルゴリズムが性能に問題を与えることは少なくなったのではないかと思います。現在の Ruby の GC の話は、何を見るのが一番いいかわからなかったんですが、とりあえず YARV Maniacs 【第 12 回】 インクリメンタル GC の導入を参考文献としてあげておきます。
さて、GC はオブジェクトの寿命管理をします。今回は、その話とは（あんまり）関係ありません。寿命管理は GC に任せて、その際に生じるメモリ割り当て・解放の話が今回の主役です。
オブジェクトを 1 つ生成すると、GC 管理の領域から 1 つ、メモリ領域を割り当てられます。このメモリ領域のことを、ここでは RValue と呼んでおきましょう。1 word をポインタのサイズとして、RValue は 5 word の固定長のメモリ領域になります。イマドキの 64 bit CPU では、8 byte * 5 = 40 byte のメモリ領域ですね。GC 対象のすべてのオブジェクトは RValue を最低限割り当てられる、ととらえても良いと思います*1。
RValue の 5 words のうち、最初の 2 words には、RBasic というヘッダが含まれています。RBasic は flags という、オブジェクトの管理に必要になる情報、および klass という、オブジェクトのクラス情報が含まれています。すべてのオブジェクトはクラスを持っているので、RValue にクラスの情報がついているわけですね。
さて、Ruby のオブジェクトには型があります。クラスとは違う概念で、この RValue をどのように利用するか、というデータ型です。例えば、文字列を格納するために使うなら T_STRING型、配列を扱うなら T_ARRAYです。型の種類は、Ruby 2.6 では 15 種類、インターナルで利用するための 4 種類（Ruby プログラムからは見えないが、インタプリタには存在する）の計 19 種類あります。この情報は、RBasic::flagsの最初の 5 bit に格納されています。
参考までに、Ruby 2.6 の include/ruby/ruby.hから、どんな型があるか、引用してみます（RUBY_ prefix は無視してもらって構いません）。
enum ruby_value_type {
RUBY_T_NONE = 0x00,
RUBY_T_OBJECT = 0x01,
RUBY_T_CLASS = 0x02,
RUBY_T_MODULE = 0x03,
RUBY_T_FLOAT = 0x04,
RUBY_T_STRING = 0x05,
RUBY_T_REGEXP = 0x06,
RUBY_T_ARRAY = 0x07,
RUBY_T_HASH = 0x08,
RUBY_T_STRUCT = 0x09,
RUBY_T_BIGNUM = 0x0a,
RUBY_T_FILE = 0x0b,
RUBY_T_DATA = 0x0c,
RUBY_T_MATCH = 0x0d,
RUBY_T_COMPLEX = 0x0e,
RUBY_T_RATIONAL = 0x0f,
RUBY_T_NIL = 0x11,
RUBY_T_TRUE = 0x12,
RUBY_T_FALSE = 0x13,
RUBY_T_SYMBOL = 0x14,
RUBY_T_FIXNUM = 0x15,
RUBY_T_UNDEF = 0x16,
RUBY_T_IMEMO = 0x1a, /*!< @see imemo_type */
RUBY_T_NODE = 0x1b,
RUBY_T_ICLASS = 0x1c,
RUBY_T_ZOMBIE = 0x1d,各データ型ごとに、T_STRINGなら struct RString、T_ARRAYなら struct RArrayのように、 5 word のメモリ領域のレイアウトを示すための構造体が定義されています。それぞれ最初に 2 word の RBasic を持っているので、残り 3 word をどのように利用するか決める、というのが、RString だったり RArray だったりの役目になります。
というところまで紹介しましたが、ちょっと不思議なことがあります。1つのStringオブジェクトが持つ文字列の長さは（メモリのある限り）いくらでも大きくすることが可能です。そのため、3 word に収まるわけがないのです。そこで、MRI はどうしているかというと、例えば RString では、1 word に malloc()で確保したメモリへのポインタ、1 word に確保したメモリのサイズ、1 word に文字列の長さを格納しています*2。この構造でしたら、扱う文字列の長さを RString の大きさに気にすることなく大きくすることが可能です。
String オブジェクトを例にご紹介しましたが、他のデータ型も、3 word で収まらない場合は同じようなテクニックを使います。
このあたりのレイアウトは、RHG が執筆された 2002 年から、ほとんど変っていません。というわけで、詳細は RHG の第2章をご参照ください：第2章 オブジェクト
さて、この malloc()したメモリですが、オブジェクトが GC によって回収されるときに free()されます。つまり、Ruby のオブジェクトがある程度の大きさのメモリを必要とする場合、生成と解放時に malloc()と free()を実行することになります。もちろん、必要なメモリ量が変更される場合（例えば String オブジェクトが破壊的に伸張されるような場合）は realloc()などを用いて確保する量を変えたりします。
現在のメモリ管理の問題点
現在の問題点は、malloc()、free()による確保・解放を頻繁に行っている、という点が挙げられると思います。細かい話はおいといて、だいたいこれくらいのデメリットがあります。
malloc/freeの操作が重い（malloc ライブラリの実装によります）- メモリの断片化が起こる
- マルチスレッドプログラミングをするとメモリを余計に食ってしまう（malloc ライブラリの実装、設定によります）
GC を持つフツーの言語処理系は、たいてい GC で管理する領域を Ruby のように固定長ではなく、可変長にして、malloc()、free()を用いないで実装されます。そのため、これらのデメリットは MRI ならでは、と言えるかも知れません。
Transient Heap のアイディア
malloc()、free()を使うとまずそう、ということがわかりました。では、どうすれば良いか。
Transient Heap （theap）は、これを解決するために導入されました。theap のアイディアを簡単に説明すると、GC と仲良くするメモリ領域です。
malloc()、free()で管理する領域の他にメモリ領域を用意して、malloc()で確保していたところを theap からメモリ確保するようにします。解放するときは、何もしません。オブジェクト回収時に free()を呼んでいたところは、何もしないように変えるだけです。GC 終了後、theap をまとめて消してしまうため、それぞれの領域を free()する必要がないんです。なんか、速そうじゃないですか。
また、theap は、単にポインタをずらすだけでメモリを確保します（bump allocation と言います。専門用語っぽくて格好いいですね）。なので、メモリ確保が malloc()より速いです。
theap 良さそうですね！
うまい話には裏がつきもので、今回の裏は「生き残るオブジェクトが余計な仕事をしなければならない」です。生き残るオブジェクトが theap を使っていると、GC 終了時に全部消されてしまうと困ります。そこで、生き残るオブジェクトが theap を使っていた場合、別の領域を割り当てて、そこにデータをコピーすることで対処します。この、別の領域を割り当て、そこにコピーすることを、ここでは 待避（evacuate）と言います。
ちなみに、すぐに（GC タイミングごとに）メモリが解放されてしまうので、「Transient（つかの間の） heap」と名付けました。
表にまとめるとこんな感じです。
| malloc/free | theap | |
|---|---|---|
| 確保 | malloc() | theap_alloc() (bump allocation) |
| 生存 | N/A | evacuate |
| 解放 | free() | N/A |
theap のほうが、確保と解放が速いです。GC での生存時、malloc/freeでは、オブジェクトの生存時には何もする必要がありませんでしたが、theap では GC が起こる度に待避が必要です。利点と欠点があるんですが、さて、どっちが得でしょうか。
そこで、たびたび世代別GCの解説で紹介される世代別仮説というものを引用します。若いオブジェクトは死にやすく、古いオブジェクトは死ににくい、のではないかという経験則です。Ruby プログラムを見ていると、若いオブジェクトをどんどん作って捨てていく、というプログラムがそこそこありそうですので、この仮説は多分正しいことが多いんじゃないでしょうか。そして、生存する率が低く、待避操作が少ないのであれば、theap はうまく効きそうです。効くんじゃないかな。効いてくれると良いな。
そこで、使えるのが以前 インタプリタ開発者によるRubyの挙動解析への道ご紹介した debug_counter を見てみます。
discourse benchmark の結果を下記に引用します。
[RUBY_DEBUG_COUNTER] obj_newobj 162,910,687 [RUBY_DEBUG_COUNTER] obj_free 161,117,628 [RUBY_DEBUG_COUNTER] obj_promote 7,289,299
この結果を見ると、promote された、つまり古い世代になったオブジェクトの数は、(7,289,299 / 162,910,687) * 100 = 4.47% と、実に 95% のオブジェクトが新世代のまま、ということがわかります。まぁそんなわけで、多分効くんじゃないかな。効いてくれると良いな。
さて、待避のためには、待避先が必要になります。この領域には2つ候補があります。再度 theap から割り当てる方法、それから従来通り malloc()を利用する方法です。一度 malloc()領域に移してしまえば、以降 theap を気にすることがありません（待避をこれ以降行う必要はありません）。そこで今回は、オブジェクトが GC における若い世代であれば、待避先に theap の領域を選び、古い世代であれば、待避先を malloc()で確保する、ということにしました。
GC のたびに領域をコピーして待避するので、コピーGC、古い世代の管理を persistent 領域（malloc()領域）で行うので世代別、なので、世代別コピー GC に似ています（アイディアはそこそこ同じです）。寿命管理は mark&sweep なので、ちょっと特殊ですね。
なお、ものすごく大きいデータを theap に確保してしまうと、いざコピーが必要になったとき大変そうなので、theap で一度に確保できる領域は 2KB に制限しています。このサイズに何か根拠があったわけではなく、当てずっぽうです。もしサイズを超える場合は、最初から malloc()して、theap を利用しないようにします。
Transient Heap の工夫：待避のタイミング
theap 良さそうです。が、いくつか問題があります。一番の問題は、素朴に実装してしまうと C 拡張ライブラリの互換性が壊れてしまう、という問題です。どういうことでしょうか。
theap を使った Arrayオブジェクトについて考えてみます。Arrayは theap から確保したメモリへのポインタを持っています。
func(VALUE ary){
/* ary から配列の実体を格納するポインタを取得 */
const VALUE *ptr = RARRAY_CONST_PTR(ary);
ptr[0]; /* (1) */
func_can_cause_gc();
ptr[0]; /* (2) */
}例えば、こんな C のコードがあったとします。ptrが theap から確保したメモリへのポインタですね。
さて、theap を素朴に実装すると、aryが参照している Array オブジェクトは生きているので、GC が起きた直後に aryの実体を待避する、というものになります。
ただ、もしそうだとすると、ソースコードの (2) での ptrアクセスが危険なものになります。というのも、ptrを取得してから (2) までの間に GC が起こってしまった場合、待避が行われてしまうので、ptrは古い領域をさすことになり、おかしなことになります。この問題は、ptrの寿命が、C 言語のソースコードの見た目と直感的に反する、という言い方もできるかもしれません（GC がらみでは、こういう問題がいくつも出てきます）。
これを避けるためには、ptrが必要になったときには、毎回 ptrを Array オブジェクトから取得しなければなりません。
func(VALUE ary){
/* ary から配列の実体を格納するポインタを取得 */
const VALUE *ptr = RARRAY_CONST_PTR(ary);
ptr[0]; /* (1) */
func_can_cause_gc();
ptr = RARRAY_CONST_PTR(ary);
ptr[0]; /* (2) */
}ただ、すでに公開されている C-extension は無数にあります。このようにすべて書き換えてください、というのは、そもそも、それを徹底するのが難しい、それから、実際に正しく書き換えるのが難しい（どこで GC が起こるか、すべてチェックする必要があります）、という問題から、現実的ではありません。
そこで、2つの工夫を行うことにしました。
待避のタイミングをファイナライザタイミングにする
GC は、いろいろなところで起きます。これを予測するのはとても難しい。
そこで、待避が行われるタイミングを、GC の直後ではなく、ファイナライザが起動するタイミングに遅延することにしました。え、なんでファイナライザ？
Ruby では、オブジェクトを解放するときに起動するファイナライザを、任意の Ruby コードで記述することができます。つまり、任意の Ruby プログラムが動き得るタイミングということになります。
任意の Ruby コードは、たとえばオブジェクトの破壊的操作を行うことができるので、C 側で取得したポインタが無効になることがあり得ます。つまり、C 側で取得したポインタは、任意の Ruby コードを実行した後では、それがそのまま利用可能かどうかわからない、ということです。
先ほどの例を見てみましょう。
func(VALUE ary){
/* ary から配列の実体を格納するポインタを取得 */
const VALUE *ptr = RARRAY_CONST_PTR(ary);
ptr[0]; /* (1) */
func_can_cause_gc();
ptr[0]; /* (2) */
}もし func_can_cause_gc()関数が任意の Ruby コードを実行するとしたら、この C 関数は危険です。なぜなら、そこで ary.replace(other_ary)といった、ptrが無効になる処理が実行されるかもしれないためです。というわけで、任意の Ruby コードを実行すると、事前に取得したポインタは保障できない、という問題は、昔からありました。C-extension 開発者は、この制限を受け入れているはずのですので、「このようなコードは無い」という仮定を置くことは妥当です*3。
そこで、任意の Ruby コードが動くタイミングで待避を行うのは妥当と言えると思います。そして、GC の後で任意の Ruby コードが動くタイミングというのが、ファイナライザを動かすタイミングなのです。
ポインタを取り出すとき、theap を無効にする
先ほど利用した RARRAY_CONST_PTR()といった、ポインタを取り出す操作を行うと、malloc()ヒープにコピーすることで、theap から待避することにしました。C-extension が扱うポインタは、これで「待避されるかも...」という不安を払拭することができます。この、theap を無効にする処理を detransient と呼んでいます。rb_ary_detransient(ary)という処理を行っています。
だいぶ保守的な決定です。theap のままなら、性能はもう少し高いままかもしれないのに。ただ、動かなくなるプログラムがでるよりは良いだろう、とこのような仕様にしました。
theap に置いたままポインタを取り出したい、ポインタを使っている間は絶対に待避を起こさない自信がある、という場合は、RARRAY_CONST_PTR_TRANSIENT(ary)を用います。detransient しません。array.cなど、私が確認したメソッドの実装については、可能な限り theap のまま扱うようにしています。どっちかなー、ちょっと考えるの面倒くさいなー、というときは、detransient してしまうようにしています。
Array を例に説明しましたが、他のデータ型においても似たような方針で実装しています。
なお、本当は、Ruby のデータ型はの内部は時々変ってしまうので、ポインタを取り出すような操作をしないのが一番です。例えば、Array でしたら RARRYA_AREF(), _ASET()などを用いるのが良いでしょう。
Transient Heap の工夫：Hash の実装
Array, Object（ユーザ定義オブジェクト）、Struct に関しては、素直に theap を用いることが出来ました。しかし、Hash はそうはいきません。なぜでしょうか。
Array の場合は、RArray から、1つの連続したメモリオブジェクトを参照します。しかし、Hash の場合はハッシュテーブルという複雑なデータ構造を用いているため（Towards Faster Ruby Hash Tables）、ぽんっと theap を用いるようにすることが出来ませんでした。具体的なハッシュテーブルの実装は、st.cと言うファイルに収められています。この st.cが提供するハッシュテーブルは、Ruby の Hash オブジェクトだけでなく、インタプリタの中で利用する表などでも利用されています。そのため、Hash オブジェクトのためだけに、ごちゃごちゃ theap 対応を入れることが出来ません。
そこで、Hash オブジェクトの実装を2つにわけることにしました。8 要素以下の場合と、8要素以上の場合です。
8要素以下では、ar_table、8要素より大きい場合は st_table（st.cが提供するテーブル）を用いる、というものです。ar_table は、Hash ではありますが、単なる配列のみで実装されており、線形探索を行います。線形探索だけど、たかだか 8 要素だから、まぁいいかなと。もうちょっと工夫してもいいかもしれませんが。
ar_table は、連続した 8B * 3 words * 8 entries = 192 byte の領域を theap から取得します。
もし、要素の追加などで 8 要素以上になれば、st_table を利用するようにスイッチします。
実は、st_table でも、省メモリ化のために 4 要素以下の場合は同じように線形探索するテーブルに変更するようにしているのですが、その処理を ar_table という形で切り出した、というのが今回の変更になります。
さて、そもそも 8 要素以下の要素数の Hash オブジェクトはどの程度あるんでしょうか。先ほどと同じく、インタプリタ開発者によるRubyの挙動解析への道から、Hash の値を確認してみます。
[RUBY_DEBUG_COUNTER] obj_hash_empty 3,632,018 [RUBY_DEBUG_COUNTER] obj_hash_under4 4,204,927 [RUBY_DEBUG_COUNTER] obj_hash_ge4 2,453,149 [RUBY_DEBUG_COUNTER] obj_hash_ge8 841,866
この例では、空の要素数が 3M個、1~3要素までが4M、4～7要素が 2.5M個、それ以上が 0.8M個と、個数が 8 未満の Hash オブジェクトが支配的です。DB 的に Hash を用いると多くのエントリ数の Hash ができますが、沢山作るのは小さい要素数の Hash のようです。キーワード引数とかで使うからですかね。
ちなみに、ar_table の導入によって、theap を用いなくても（すべて malloc()で確保しても）若干 st_table よりも効率が良くなるケースが出てきました。
Transient Heap の工夫：その他
他にもいろいろ、ちゃんと動くようにするため、思ったよりも苦労しました。
- ファイナライザタイミングまで遅延することと、旧世代オブジェクトとの食い合わせが悪かったので、いろいろ頑張った
- 省メモリにするため、いろいろとケチケチするテクニックを使った
- デバッグが大変だったので、書き込み禁止メモリを用いるオプションを作った
- それでも後から後から、「時々」出現するバグが見つかるので、テストを沢山実行した
他にもあったような気がしますが、思い出せない。
面倒なので、詳細は割愛します。
Transient Heap の評価
実際、どの程度速くなるんでしょうか。少し評価をご紹介します。
どれくらい theap を使っているか
debug_counter に theap を使っているかどうかを見るカウンタを新設したので、それでチェックしてみましょう。
実行するのが簡単なので、rdoc ベンチマークの結果を見てみます。
# Object [RUBY_DEBUG_COUNTER] obj_obj_embed 11,360 [RUBY_DEBUG_COUNTER] obj_obj_transient 541,445 [RUBY_DEBUG_COUNTER] obj_obj_ptr 47,567 # Array [RUBY_DEBUG_COUNTER] obj_ary_embed 8,261,454 [RUBY_DEBUG_COUNTER] obj_ary_transient 2,818,104 [RUBY_DEBUG_COUNTER] obj_ary_ptr 558,292 # Hash [RUBY_DEBUG_COUNTER] obj_hash_empty 523,811 [RUBY_DEBUG_COUNTER] obj_hash_under4 541,901 [RUBY_DEBUG_COUNTER] obj_hash_ge4 1,598 [RUBY_DEBUG_COUNTER] obj_hash_ge8 2,432 [RUBY_DEBUG_COUNTER] obj_hash_ar 1,066,943 [RUBY_DEBUG_COUNTER] obj_hash_st 2,799 [RUBY_DEBUG_COUNTER] obj_hash_transient 955,418 # Struct [RUBY_DEBUG_COUNTER] obj_struct_embed 791,055 [RUBY_DEBUG_COUNTER] obj_struct_transient 1,351,924 [RUBY_DEBUG_COUNTER] obj_struct_ptr 543,895
Object は 90%、24%（ただし、埋め込み Array を排除すると83%）、Hash は 89%、Struct は50%（埋め込み Struct を除くと 71％）と、結構支配的です。きちんと、theap が活用されていることがわかります。
[RUBY_DEBUG_COUNTER] heap_xmalloc 8,244,862 [RUBY_DEBUG_COUNTER] heap_xrealloc 318,127 [RUBY_DEBUG_COUNTER] heap_xfree 7,905,729 [RUBY_DEBUG_COUNTER] theap_alloc 7,332,681 [RUBY_DEBUG_COUNTER] theap_alloc_fail 583,852 [RUBY_DEBUG_COUNTER] theap_evacuate 1,257,952
こちらでは、mallocした回数と、theap から確保した回数（theap_alloc）が見て取れます。malloc回数と同程度の回数、theap で割り当てていることがわかります。原因をさがしたら、もうちょっと theap の率を増やすことができるかもしれません。
待避（theap_evacuate）したのは、17% 程度みたいですね。そこそこ少なそうです。
theap_alloc_failは、theap から確保しようとしたが、何らかの理由で失敗した数です。もうちょっと減らせそうですね。
マイクロベンチマーク
次のグラフは、対応している Array オブジェクトの要素数を変えながら、沢山作るのを繰り返す、というものを、 theap ありとなしで比べた結果です。
このマイクロベンチマークでは、だいたい、1.5 倍程度の性能向上が得られているのがわかると思います。
Hash もだいたい 1.5～2倍程度の性能向上を実現しています。ただ、9要素になると theap を使わないため、以前と同程度の性能になります。
実アプリケーション
rdoc
USE_TRANSIENT_HEAPというマクロを 0 にすると theap を無効にできるので、オンとオフ、それぞれを調べてみます。
# without theap
user system total real
23.757590 0.363964 24.121554 ( 24.124386)
VmHWM: 423932 kB
# with theap
user system total real
22.334208 0.355940 22.690148 ( 22.693046)
VmHWM: 358584 kB時間は 24.12/22.69 = 6% ほど速くなっています。良かった良かった。
VmHWM は、Linux だと取れる、必要になった実メモリのサイズですが、なぜか 18% ほど削減しています。あまりちゃんと調べていないし、他のアプリではどうか、という調査はしていないのですが、とりあえず「良かったね」と捉えておきます。
sinatra-benchmark
https://github.com/benchmark-driver/sinatraを用いてみました。
Calculating -------------------------------------
without-theap with-theap ruby_2_5
sinatra 10.293k 10.493k 10.263k i/s - 100.000k times in 9.714985s 9.530253s 9.743398s
Comparison:
sinatra
with-theap: 10492.9 i/s
without-theap: 10293.4 i/s - 1.02x slower
ruby_2_5: 10263.4 i/s - 1.02x slowerうーん、2% 速いらしい。微妙ですね...。
discourse
discourse rails benchmark で試したんですが、ちょっと手元に結果がないのですが、たしかさっぱり変らなかった気がします。
この辺は、そもそも malloc/free自体があまりオーバーヘッドになってないってところでしょう。まぁ、そうですよね。でも、もうちょっと効くと思ったんだけどなあ。
速くなった！ という話があれば、お寄せ下さい。
transient heap seems to explain some of the performance increase, but maybe not all (though I'm using Ruby 2.5 from rbenv) /cc @_ko1pic.twitter.com/aJPkL75hCV
— Aaron Patterson (@tenderlove) December 19, 2018
こんな話もあるみたいです。
まとめ：Transient Heap
いろいろ複雑な工夫を入れた割に、Rails とかで効かないとか、イマイチ感動の少ない工夫ではありますが、効くところではもしかしたら効くかもな、という感じです。
一番 theap が効きそうな String ですが、対応していません。C レベルで、すぐにポインタを取り出す処理をしてしまうので、あまり効果がないためです。効果を出すためには、絶対に待避されない、ということを保障する必要がありますが、それを行うのが大変なのですよね。というわけで、将来のバージョンでは対応するかもしれないし、そもそも効果が無いから theap 自体が削除されるかもしれません。効くアプリには効きそうなんですけどねぇ。
もう一つ。現在 theap 用のメモリ領域は、最初に 32MB 固定長を確保しています。これを可変に、必要なときに多く、不用なときには少なく、みたいにするのも手かもしれません。現状は、その辺の調整が難しくて（例えば、OS に返す、要求する、を繰り返すと、とても遅くなります）、手を入れられていません。
おわりに
本稿では、私が Ruby 2.6 に導入した次の2つのトピックについてご紹介しました。
- TracePoint の拡張
- 新しいイベント script_compiled の導入
- フックを有効にする場所を制限する機能の導入
- デバッガの実装が、10～100倍くらい速くなる、かもしれない
- ブレイクポイントの実装を例に解説
- Transient Heap の導入
- 短寿命メモリオブジェクトの高速化
- 世代別コピーGCのアイディアを利用
- Rails とかには効かないかも...。
三日連続で Ruby 2.6 の新機能をお伝えしました。いつになく長い記事になりましたが、冬休みにでもお楽しみ頂ければ幸いです。
では、良いお年をお迎えください。