めんどいので簡潔に


  • DTraceではself->variable構文をつかうと、per CPU variableを使うので var[hash] よりも速い事が保証されている。連想配列あるからいいじゃんとか言ってるSystemTapは空気読めてない子
  • DTraceではAggregation関数で集計すると自前で var += hoge とかやって集計するよりも速い事が保証されている。これは言語の使用目的を考えると必須だよな。とか思った
  • DTraceは収集時にAggregate関数の種類を選ぶが、SystemTapは表示時に選ぶ。DTrace方式のほうが無駄な収集が発生しないので賢い
  • Speculative Tracingってなんじゃらほい？と思ったら単に主バッファとは別のバッファがつかえるよ。
    というだけだった。でも構文は汚いと思う

    • バッファアロケートが関数なので、実行時にしか何個バッファが生成されるか分からない。
      どう考えても普通はせいぜい１つしか作らないので、柔軟性より速度を追求した方がよい
    • 書き出し先バッファ切り替えが関数なので汚い。どうせ１関数内で複数のバッファに書くことは
      言語使用上禁止されているのだから関数の修飾子とかにしたほうがよかった気がする

  • early boot tracingはかなりがんばっている。SCSI やFilesystemより先にロードされてるんだけど
    　どうやってるんだ？
  • SolarisではELFを独自に拡張してDTrace用のSymbol Tableを別途持っている。かつこれはstripの
    対象外なので、stripされたバイナリからでもシンボルが引ける。これはユーザアプリのトレースで
    重要な性質。static関数もちゃんとテーブルに名前が残ってるし。SystemTapは行番号トレースと
    ローカル変数の参照をサポートしたぶんだけ、必要な情報量が爆発的に増えており、事実上
    DWARFを使うしか手がない。
    stripされたバイナリをトレースできるようにするのは、仕様変更がいるなぁ
    　　http://blogs.sun.com/ali/entry/what_is_sunw_ldynsym
    　　http://blogs.sun.com/ali/entry/inside_elf_symbol_tables
  • バッファポリシーとして

    • switch
    • fill
    • ring

    の３つをサポート。switchがデフォルト。
    　残り２つはearly boot tracingと組み合わせて使う。
    　fillがバッファがいっぱいになったらこれ以上記録しない。というバッファ。ブート時のログを
    とりたいときはバッファがいっぱいになったら自動的に止まって欲しいからね。
    ringは逆にバッファがいっぱいになったらバッファ先頭にもどって上書きしていく。
    んで、なんかおかしくなったときに、最後のほうのログを吸い出す。
    いわゆるフライトレコーダー目的
  • ユーザ空間のトレースはある関数の全instructionにprobeをしかける。とか出来るので、
    エラーが発生した箇所を細かく絞り込むことが（根気が許せば）可能
  • profile provideはトレース間隔に109とか4999とか変な数値がデフォルトになっているが、
    　キリのいい数字にすると毎回クロック割り込みとぶつかっておかしな集計結果になるから。
    賢い


とりあえず、SystemTapも.SUNW_ldynsymをサポートして「でもstripされていたら行番号トレースはできないからね」という仕様にしたほうがLKMLでdisられなくなっていいんでは？とか思った