基于嵌入式设备浏览器内存管理策略研究
(2)管理策略二：具有Compaction机制的Vector分配策略。在Browser中，除了结构大小固定的对象频繁分配和归还外，经常有大量大小不同的对象分配和归还，目前，这种现象主要出现在处理TextBox这一块内容上，这些大小不向的对象具有如下特点：其一是对象的分配和归还是随机发生的；其二是对象可以在其生命过程中改变自身大小。如果直接利用系统函数进行分配和释放，在总内存比较小的嵌入式系统中会造成过多的碎片，从而浪费了大量内存空间。具有Compaction机制的Vector通过移动“继续在用对象”来移除“继续在用对象”之间的“已经废弃不用的对象”，从而把“继续在用对象”移成连续排列，而“已经废弃不用的所有对象”所占用的空间解放出来放到地址空间的某一端，对它们进行循环使用，移动对象，最富有挑战的问题在于保证原来对内存空间的引用都被正确更新。当某个对象移往一个新位置，所有指向原地址的指针都将失效。虽然技术上有可能找出每一个移动对象的原有指针并更新之，但通常引入一个额外的间接层会使问题更简单：用户引用的是指向对象表中一个项目栏内对象的“handle”，而不再直接指向对象地址，“handle”是指向某对象真实地址的“惟一”指针，对象表中一个项目栏内有代表handle的addr、有表示对象所占空间的大小size和用于标志对象所占空间是否为“继续在用对象”还是“已经废弃不用的对象”的标志位mark。图4表示了对象引用、对象表和实际对象的三者关系。当内存中移动“继续在用对象”的时候，只需要更新对象表中相对应项目栏中代表handle的addr，使它指向对象的新地址，其他所有引用都可以继续正确地访问该对象。这里返回给用户的引用是对象表的索引，用户再通过索引获得相对应的handle指针addr，为了使用户快速获取可用索引，建立了50个可用索引的buffer。本文引用地址：//m.amcfsurvey.com/article/150448.htm
如果对许多对象执行Compaction，那么整个Compaction过程是比较费时的，因此，什么时候执行Compaction将对一个应用程序的执行效率有着重大影响。原则是：在内存空间和可用索引能够满足分配的情况下，能不要Compaction就不要执行Compaction。因此建立了两个执行Compaction的触发点，一个触发点是当用完了预分配1 000个索引值时；另一个触发点是当没有可用内存空间用于分配时触发。结果，在许多情况下避开了Compaction过程。对于管理索引值问题，采用了如下简单算法：先取前50个索引值放到Index Buffer中，用完50个索引值以后，再取50个索引值放入Buffer中，直到预分配的1 000个索引值用完为止，这时执行Compaction，然后按顺序搜索对象表，如果对象表表项标志为可以重复利用，则把这个对象表表项的索引加入到Index Buffer之中，直到填满Index Buffer为止；如果1 000个索引值已经全部用完，则按100为单位动态增加索引值。在Vector中，存放对象表需要一些额外的空间，大量对象的Compaction会占用比较多的时间，从而降低时间效率。
3 Browser内存管理的性能分析
Browser分别调用自己应用程序级的内存管理的接口与系统级的内存管理的接口进行运行比较，结论是应用程序级的内存管理效率比系统级的内存管理效率要高，网页越大，体现出来的效率越高。
3．1 池式分配内存使用情况
对于Browse中各种固定大小的结构(这种结构称谓thing)，分别用相对应的一个内存池(pool)进行管理，各个pool形成一条pool链，内存管理器在执行一段时间后会按照各个pool的调用频率高低对pool链进行排序，从而提高了查找pool的效率。用小网页、中等大小网页和大网页对pool链中的各个pool进行测试，得到如图5所示的结果。
linux操作系统文章专题:linux操作系统详解（linux不再难懂）
评论