4

Freescale MX51 ベースのボード Linux 2.6.35 で GUI を多用する C++ アプリケーションを開発しています。ヒーププロファイリングを実行したいと思います。

残念ながら、私が見つけたすべてのヒープ プロファイリング ツールは、侵入的すぎるか、表向きは ARM で動作しませんでした。私が試した特定のツール：

  • Valgrind Massif : プラットフォームの CPU が弱いため、私のプラットフォームでは動作しません。Massif によって導入された 80% の CPU 時間のオーバーヘッドは、私のアプリケーションで補償できないさまざまな問題を引き起こします。
  • gperftools (以前の Google パフォーマンス ツール) tcmalloc:ヒープ プロファイラーを除いlibc malloc()て、このやや邪魔にならないライブラリ ベースの置換のすべての機能がターゲットで動作し言い換えると、スレッド キャッシング アロケーターは機能しますが、プロファイラーは機能しません。興味のある方のために、以下でプロファイラーの失敗モードについて説明します。

ARM プラットフォームで C++ ヒープ プロファイリングを実行するための一連の代替ツールを提案できる人はいますか? 理想的な出力は、最終的に gperftools の tcmalloc 出力と同様の有向割り当てグラフになります。リソースの使用率を低く抑えることは必須です。私のプラットフォームはリソースに非常に制約があります。

gperftools の tcmalloc の失敗モードの説明:

この情報は、興味のある方のみに提供しています。返事は期待しない。x86 ではなく ARM を除いて、以下の gperftools の問題 #407 に似た問題が発生しています。具体的には、「フックされたアロケータ フレームが見つかりません。空のトレースが返されました」というメッセージが常に表示されます。この問題のデバッグに時間を費やしたところ、tcmalloc ライブラリを動的にリンクすると、アプリケーションと動的ライブラリの間の境界にあるフレーム ポインタが null になり、スタックを動的ライブラリへの呼び出しの「上」に移動できないようです。

gperftools の問題 #407: https://github.com/gperftools/gperftools/issues/410

ARM で同様の問題が発生しているスタックオーバーフロー ユーザー: ARM の共有ライブラリでフレームが見つからない

4

1 に答える 1

2

ヒープ。それらを行うには多くの方法がありますが、私は埋め込まれた土地で重要な3つの主要なタイプにしか遭遇していません。

  1. リンクリストのヒープ。各割り当ては、「使用済み」リストで追跡されます。解放されると、それらは「無料」リストにドロップされます。解放すると、隣接する空きメモリのブロックが「結合」されて大きな部分になります。Allocは任意のサイズにすることができます。各allocとfreeはO（N）opです。これは、空きリストをトラバースしてメモリの一部を提供し、残りのブロックを空きリストに残したまま、空きブロックを要求したサイズに近いサイズに分割する必要があるためです。割り当てごとのオーバーヘッドが増加するため、このシステムを小規模なシステムで単独で使用することはできません。また、これを最小限に抑えるための手順を実行しないと、時間の経過とともにメモリの断片化が発生する傾向があります。

  2. 固定サイズ（単位）のヒープ。ヒープを同じサイズ（小さい）の部分に分割します。これは、チャンクの大きさ（および作成するさまざまなサイズの固定アロケータヒープの数）に応じてメモリを少し浪費しますが、allocとfreeはどちらもO（1）時間の操作です。検索も参加もありません。私が使用したエンジンでは、割り当ての95％が設定されたサイズ（たとえば256バイト）未満であるため、このスタイルは「小さなオブジェクトの割り当て」の最初のスタイルと組み合わされることがよくあります。このように、小さな割り当てにはユニットヒープを使用して、大きな速度と最小限のメモリ損失のみを実現し、大きな割り当てにはリストヒープを使用します。メモリの外部断片化もありません。

  3. 再配置可能なメモリヒープ。メモリへのポインタを与えるのではなく、処理します。そうすれば、舞台裏で、断片化などを削除するために必要なときにメモリポインタを変更できます。高いオーバーヘッド。@ $$の商は悪用されやすく、ダングリングポインタがいたるところにあるため、非常に苦痛です。また、メモリの逆参照ごとにオーバーヘッドが追加されました。しかし、それについて言及したかった。

いくつかの基本的なパターンがあります。それらを使用し、割り当て数、断片化、およびその他の有用な統計の統計が組み込まれている、あらゆる種類のライブラリを実際に見つけることができます。自分でロールするのも難しいことではありませんが、mallocを機能させずにデバッグするのは確かに苦痛なので、好奇心を満たす以外の目的にはお勧めしません。スレッドサポートの追加も非常に簡単ですが、ここでも、既製のソリューションをダウンロードすることをお勧めします。

上記の情報は、ARMまたはその他のすべてのプラットフォームに適用されますが、私の経験のほとんどは低レベルのARMのものであるため、上記の情報はプラットフォームでテスト済みです。お役に立てれば！

于 2012-07-17T16:54:47.177 に答える