Embedded ARM上的堆分析 我在Flash的MX51板上开发了GUI重C++应用程序。strong>我想执行堆分析。

不幸的是，我发现的所有堆分析工具要么过于侵入性，要么表面上无法在ARM上工作。我尝试过的特定工具：

• ：在我的平台上无法运行，因为平台的CPU很弱。Massif引入的80%CPU时间开销在我的应用程序中造成了一系列无法弥补的问题
• （以前的Google性能工具）tcmalloc：这个基于库的非侵入性

  libc malloc（）

  替换的所有功能都可以在我的目标上工作，除了heap profiler。换言之，线程缓存分配器工作，而探查器不工作。我将在下面向好奇的人解释探查器的故障模式

是否有人建议在ARM平台上执行一套用于执行C++堆分析的替换工具？理想的输出最终将是一个定向分配图，类似于gperftools的tcmalloc输出。资源利用率低是必须的-我的平台资源高度受限

---

gperftools的tcmalloc的故障模式说明：

我只为那些好奇的人提供这些信息；我不期望得到答复。我在下面看到了类似于gperftools的问题#407，除了在ARM上，而不是在x86上。 具体地说，我总是收到消息“Hooked allocator frame not found，returning empty trace”。我花了一些时间调试这个问题，当动态链接tcmalloc库时，我的应用程序和动态库之间的边界上的帧指针为空-堆栈无法在“上面”遍历对动态库的调用

GPERF工具问题#407：

---

stackoverflow用户在ARM上看到类似问题：

堆。有很多方法可以做到这一点，但我只见过3种主要类型的嵌入式土地：

链表堆。在“已使用”列表中跟踪每个alloc。一旦释放，它们将被放入“自由”列表中。释放时，相邻的可用内存块被“连接”成更大的块。Allocs可以是任何大小。每个alloc和free都是一个O（N）op，因为它必须遍历空闲列表以给您一块内存，并将空闲块拆分为接近您要求的大小，同时将剩余块保留在空闲列表中。由于每个alloc的开销不断增加，该系统不能在较小的系统上单独使用。如果不采取措施将内存碎片最小化，这也会随着时间的推移导致内存碎片

固定大小（单位）堆。将堆分成大小相等（更小）的部分。这会浪费一些内存，这取决于块的大小（以及您创建的不同大小的固定分配器堆的数量），但是alloc和free都是O（1）时间操作。没有搜索，没有加入。这种风格通常与第一种“小对象分配”风格相结合，因为我使用过的引擎95%的分配都低于设定的大小（比如256字节）。通过这种方式，您可以对小的alloc使用单元堆以获得巨大的速度和最小的内存损失，而对较大的alloc使用列表堆。也没有外部内存碎片

可重定位内存堆。您不会给出指向内存的指针，而是句柄。这样，在幕后，您可以在需要删除碎片或其他内容时更改内存指针。高开销。高痛苦是@$$商，因为它很容易被滥用，并得到到处悬空的指针。还增加了每次内存取消引用的开销。但是我想提一下

有一些基本的模式。您可以在野外找到各种使用它们的lib，并且还内置了alloc数量、碎片和其他有用统计信息的统计信息。这也不是很难实现自己的功能，尽管我不推荐使用它来满足好奇心之外的任何东西，因为在没有工作malloc的情况下进行调试确实很痛苦。添加线程支持也很简单，但是下载现成的解决方案是更好的选择

---

以上信息适用于所有平台，无论是ARM还是其他平台，尽管我的大部分经验都是关于低级别ARM的，所以以上信息是针对您的平台进行战斗测试的。希望这有帮助

哇，所以512MB是“高度资源受限的”…呼应了我对GBA/DS编程的想法：）