[ruby-dev:39959] Re: Fwd: [ruby-cvs:33451] Ruby:r26235 (trunk): * trace.h: new file. wraps tracing mechanisms.

　ささだです．

　説明，ありがとうございます．

(2010/01/04 17:09), Yugui wrote::
> OSX付属のruby(1)およびMacRubyのdtraceサポートを参考に、Rubyの各所に対して
> アプリケーションを実行時にトレースするための観測点を埋め込みました。
> 観測点は結局set_trace_funcのものと重なる物も多く、そういったものはVMのtrace命令
> の実装の中に埋め込んであります。その他は観測点は全体に散らばっています。

　trace 命令を必要なときに埋め込むようにする，という話もあったりなかった
りしますが，その辺とバッティングしないだろうか．埋め込む API が明確化さ
れればいいか．

> ruby.hの変更は2点です。オブジェクトの生成というのは是非トレースしたいタイミングですが、
> 生成されるオブジェクトのVALUE値およびクラスを確実に知ることのできるタイミングはOBJSETUPしかありません。
> そこでOBJSETUPに観測点を追加しました。

　我々が研究で作っているプロファイラでは，OBJSETUP でのタイミングでは必
要な情報が取れない，ということで，次善策をとることにしました．これは，今
作業中なので詳細は略．

　でも，やりたいことはこれで全部出来るのかなぁ．

> 次に、殆どの場合は観測点は有効化されていないと考えられるので、このことをコンパイラに知らせるために
> 従来VMで使用していたLIKELYとUNLIKELYのようなものが必要でした。OBJSETUPの必要な場所ではUNLIKELY
> が必要になる可能性があるわけですから、ruby.hに書くのが適切です。そこでVMからruby.hに両マクロの定義を移動させました。

　LIKELY，UNLIKELY はたしか Linux のソースから取ったような気がするんです
が（Binary Hacks で読んだんだっけ），十分に一般的な名前なんでしょうか．
私がこれを導入したときは，VM の中だけだから，まぁいっかぁ，とあまり考え
ずに使いました．

　これを，全 C拡張ライブラリ開発者が使えるようにするためには，もう少し議
論が必要な気もします．が，杞憂でしょうか．個人的には，もう少しわかりやす
い名前がいいと思うのですが．例えば，分からない人がてきとーに書いちゃう不
安はないでしょうか．

>> この辺の狙いを教えて頂けないでしょうか．変更をあんまり読めていないので
>> すが，そもそも，Ruby のトレースまわりを全部書き換えちゃったりするんで
>> しょうか．
> 
> 狙いは、Rubyアプリケーションの実行時に、アプリケーションを改変することなく外部から状態を計測することです。

　「DTrace を持つ環境下では」で，一般的な話じゃないですよね．これから
DTrace が一般的になっていくのかもしれませんが，現在はそうじゃないわけで．

> 今回、まずは非有効時のオーバーヘッドが少ない技術としてdtraceの上に実装してみましたが、
> dtraceべったりではないので他のメカニズムも実装すれば、configure時に選択可能です。
> usaさんからwindowsだとETWもありえるという指摘をいただきました。
> traceやprobeのような一般的な名前はdtraceべったりでなくした結果です。

　まず，標準の probe ライブラリとするためには，

(1) probe の挿入点の妥当性の検証
(2) probe の挿入点の名前の検証
(3) 実装方法の検証

が必要かと思います．(1)〜(3) まで，どれもまだという認識でいいでしょうか．

　コミットされないと検証もままならない，という意見があるかと思います．

　個人的には，(3) 実装方法に関して，の DTrace 依存が当分外れることはない
と思うので，標準的な名前になることに違和感があります（私が普段使う環境に
はないし）．(1)，(2)，および (3) の詳細に関しては，まだよく見てません．

　DTrace のサポートを受けることが出来るようにすることは，意味があると思
います．ただ，それなら (a) DTrace 専用であることを謳う（Win32OLE みたい
に，専用ぽくする） (b) gem で標準っぽいものを作って試行錯誤し，標準添付
を狙う，なんて方針もあるんじゃないかと思います．

　あと，set_trace_func の挙動が rescue もひっかけるようになってしまって
変わってしまったということを IRC で聞きました．この辺の挙動の変更は，今
回の話とは直接関係なさそうですから，別途議論したほうがいいのではないで
しょうか．多分，増えて困る人はあまり居ないと思いますが．


>> あと，出来ればベンチマーク結果があると嬉しいかも（prove を刺さない状態
>> での）．
> 
> あー、計ってからコミットしようと思っていて忘れてました。やってみました。添付します。 (wo_w-dtrace.log)
> リビジョン番号が新しいほうがdtraceを入れたやつです。
> 
> なお、意外にオーバーヘッドが大きいように見えました。特に命令をひたすら繰り返す系統が遅いので、試しにYARV命令ごとのトレースを削除して再度計ってみました。
> そちらがwo_w-dtrace2.logになります。他のトレースメカニズムを取り入れると、もっとオーバーヘッドが大きいことも考えられますし、
> 命令ごとのトレースはデフォルトで無効にしたほうが良いかも知れませんね。

　命令ごとのトレースもあるんですね．短い命令は数語なので，いくら分岐予測
が働いたとしても，3 命令のオーバヘッドは大きいのかもしれません．

　あと，ベンチマーク1回だけの実行は擾乱が大きいので，5 回くらいやっても
らうといいかもしれません．

  $ make benchmark COMPARE_RUBY='before:: [before path]' OPTS='-r 5'

みたいな．

-- 
// SASADA Koichi at atdot dot net