フレームポインタの復活

Brendanのサイト: はじめに

• Brendan Greggのブログのホームページでは、システム性能、BPFツール、Linux性能などに関するさまざまなテーマを扱っている。
• 最近の投稿には、フレームポインタの復活、eBPFドキュメンタリー、eBPF観測ツールはセキュリティツールではない、といった内容が含まれている。
• ブログでは技術的な内容に加えて、Brendanが参加したさまざまなカンファレンスや発表内容も共有している。

フレームポインタの復活

• フレームポインタのないシステムでは、スタックトレースがlibcレイヤーで止まり、アプリケーションフレームが欠落する。
• FedoraとUbuntuは、デフォルトでフレームポインタを含めてlibcをコンパイルした版をリリースすることで、この問題を解決した。
• フレームポインタは外部プロファイラやデバッガによって使用され、フレームグラフによって可視化される。

フレームポインタとは?

• x86-64 ABI文書によれば、CPUレジスタ %rbp をスタックフレームの「ベースポインタ」として使用できる。
• この技術はスタックトレースのために広く使われており、Linux perfやeBPFなどによって利用される。

2004年: フレームポインタの削除

• 2004年にgcc開発者のRoger Sayleが、フレームポインタ生成を停止する変更を進めた。
• この変更は性能向上をもたらしたが、eBPFの登場により、今日では一部のデバッガ/プロファイラがこれによって問題を抱えている。

2005-2023年: 壊れたプロファイラの冬

• フレームポインタ削除の変更はx86-64にも適用されたが、このアーキテクチャはより多くのレジスタを持っているため、大きな利得はなかった。
• その結果、多くのデバッガ/プロファイラが正しく動作しなくなった。

2014年: Java in Flames

• Netflixに参加したとき、Javaのフレームポインタ対応不足がすべてのアプリケーションスタックを壊していることを発見した。
• この問題を解決するために、JVM c2コンパイラ向けの修正を開発した。

2015-2020年: オーバーヘッド

• すべてにフレームポインタを追加することによる性能オーバーヘッドは、一般的には1%未満である。
• 特定のマイクロベンチマークでは、オーバーヘッドが10%に達することがある。

2022年: アップストリームへの試み

• Google、Meta、Netflixなどの大企業が、すでにあらゆるものにフレームポインタを有効化していたことを示唆している。
• こうした変更を皆に利益があるようデフォルト設定にするには、いくつもの困難がある。

2023年、2024年: FedoraとUbuntuでのフレームポインタ

• Fedoraは、フレームポインタを再有効化する提案を受け入れた。
• Ubuntuも24.04 LTSで、デフォルトでフレームポインタを有効化した。

2034年以降: フレームポインタを超えて

• スタックを追跡する方法には、LBR、BTS、AET、DWARF、eBPFスタックウォーキング、ORC、SFrames、シャドウスタックなど、さまざまなものがある。
• 将来的には、SFramesやシャドウスタックがすべてのスタックトレースに使われる可能性がある。

結論

• フレームポインタの復活は、CPUフレームグラフをより意味のあるものにし、Off-CPUフレームグラフを初めて機能させ、さらに新たな可能性を切り開く。
• これは継続的プロファイラにとっても勝利であり、プロファイラを完全に動作させるために顧客を説得してOS変更を行ってもらう必要がなくなる。

GN⁺の意見

• フレームポインタの復活は、システム性能分析とデバッグに大きく役立つと見られる。特に複雑なソフトウェアシステムで問題を診断し、性能を最適化するうえで不可欠なツールである。
• このような変化は、オープンソースコミュニティにおける協力と貢献の重要性を示している。FedoraとUbuntuの決定は他のディストリビューションにも影響を与える可能性があり、Linuxエコシステム全体に前向きな変化をもたらすだろう。
• フレームポインタの再導入は、性能低下とデバッグのしやすさの間でバランスを取る問題である。このような決定は、実際の運用環境での性能テストと分析を通じて、よりよく理解できる。
• 技術的な背景を持つユーザーにとって、この変化は興味深いものになり得るし、システム性能向上に関心のある開発者やシステム管理者に有用な情報を提供する。
• フレームポインタと似た機能を提供する他の技術やツールがあるなら、たとえばIntelのVTune ProfilerやAMDのuProfのようなハードウェアベースのプロファイラを利用できる。これらのツールはフレームポインタがなくても性能分析を可能にする。

[GN⁺]

Hacker Newsの意見

• 2000年代初頭にスタックフレームポインタの省略が広まり始めた頃の経験
  • 筆者は当時コンピュータサイエンスを学んでおり、使っていたコンピュータは古くて低性能だった。
  • デバッグが難しくなったため、Pythonを使い始めることでデバッグの問題を避けた。
• Fedoraディストリビューションでスタックフレームポインタを維持するための取り組み
  • スタックフレームポインタには大きなオーバーヘッドがあるという誤った思い込みがあったが、実際のオーバーヘッドは1%未満である。
• AppleがARMアーキテクチャでスタックトレースを常に意味のある形で維持してきた点
  • 特定の関数はフレームレコードを生成しないことがあるが、スタックトレースはデバッグ情報がなくても有意義である。
• Googleでの経験と、コミュニティとの20年にわたる議論
  • libunwindをgperftoolsに適用するためのパッチ作業および保守経験の共有。
• 過去に-fomit-frame-pointerオプションで性能向上を経験した事例
  • 32ビットプロセッサでMySQLとPHPをコンパイルし、ハードウェアコストを削減した。
• Virgilプログラミング言語のスタックフレーム管理方法
  • 動的なスタック割り当てがない場合、単純なテーブル参照でフレームサイズを見つけられる。
  • メタデータデコードを実装するコードについての説明。
• スタックを「歩く」代わりにRBPとRSPを使って2つのスタックを管理するというアイデア
  • 呼び出しスタックが単なるリターンアドレス配列になることで、スタックウォークの必要性が減る。
• フレームポインタ支持に関する経験や考えの共有
  • フレームポインタを有効にするかどうかはケースごとに決めるべきであり、ベンチマークが重要である。
  • ビルドシステムがこれを全体的に変更できる機能を提供することの重要性。
  • SFrameへの期待と、現在の問題を解決する可能性。
• プロファイリングが20年間問題であり、ようやく解決されたという意見
  • フレームポインタの不在は多くの人にとって苦痛であり、今Linuxがそれを元に戻すのを見ると、彼らの努力が認められたように感じられる。
• システムプロファイリングを可能にするメカニズムの性能に対する不満は逆説的である
  • 性能問題を特定できるようにしてくれるシステムへの性能面での不満は、性急な最適化の極致である。