标签： memory

BREW使用C++及内存检测

很早之前，我第一次接触BREW的时候，他们告诉我说只能用C，那个时候，BREW好像刚出到SDK 2.1,也说不定没出来，后来，我用C的struct来模拟C++的类及Java类。第一次的接触大概持续了不到两个月，第二次的接触却在两年之后，而这次，接触的也大部分是C的代码，通过查看编译器的资料，知道可以对C++进行大部分支持了，而这一次，却持续了3年之久，并且可能还会持续一段不小的时间。
话题扯远了，第二次的时候，看了下别人的C++代码，每个类里面都要重载new,delete,对于类似我这样的懒人实在是不方便，于是就写了个重载全局new,delete等函数的代码，如下所示：
继续阅读BREW使用C++及内存检测

自己实现内存分配

很早之前，我们就在讨论自己实现内存分配的必要性，既然系统已经实现了内存内存分配，我们为何要多此一举？我们是否可以认为系统的内存分配是高效的？很自然的观点，自己实现内存分配没有系统的高效，我到现在依然保持这样的观点（对于成熟的系统）。我们找了很多理由来说明它的不必要性，却又找了很多理由来说明它的必要性。先看下历史缘由吧（即使在现在依然在进行中）：
BREW系统中无法使用高级的C++，自然包括异常(ADS1.2编译器)，这样，如果一个很深很深的函数中，某个地方内存分配失败，为了确保程序的正常运行，必须进行检查，告诉用户内存不够了，而我们又不能使用try…catch机制，只能在每个内存分配之后进行检查。这是一种让人烦恼的情况，必须进行解决。
继续阅读自己实现内存分配

BREW中对malloc和free检测内存泄露

大约3到4年前，我刚刚开始对BREW进行深入的了解和开发。面对的都是C代码，里面充斥着MALLOC和FREE的调用，难道他们就不会封装一下吗？问题在于，程序可能不是自己写的，嗯，程序的某个地方，在某个时机可能会产生内存泄露；程序在退出时，系统不会自动释放占用的内存吗？答案是NO，直到关机之前，BREW都不会帮你释放，包括最新的BREW 4.0系统。而kddi对此也进行了非常严格的重视，程序进入之前剩余内存和程序退出之后剩余内存误差在5KB之内。系统本身会造成一些内存浪费(碎片)，即使在这种情况下，也要求误差5KB。想象一下，查找一个地方的内存泄露是多么的麻烦。因此，换个角度，是否让程序来帮助我们查找，当然，答案是肯定的，不然，我就是在骗人了。
继续阅读BREW中对malloc和free检测内存泄露