保持CC++程序代码的可伸缩性

今天，许多32位应用程序认为32位平台上可用的虚拟内存在某种程度上是有限的。对于程序开发人员来说，即使当他们开始关注64位平台时，他们也必须维护32位版本的软件，这需要一种方法来保持两个版本的代码都具有相当的可伸缩性。

目前，的内存分析工具可以帮助确定程序达到内存使用峰值时会发生什么，但这些工具都过于关注分配的内存块，而不是提交的虚拟内存地址空，这两个指标之间没有直接的相关性，例如内存泄漏、内存碎片、内存块中的空浪费或内存单元重新分配的过度延迟。IBM Rational Purify或Parasoft Inuse等运行时分析工具可以提供内存泄漏和已用内存的描述，非常有用。然而，一个特殊的内存块可能会也可能不会影响虚拟内存覆盖区域。此外，即使是碎片内存堆中的一个小块也会直接影响虚拟内存覆盖区域。另一方面，这个范围内的任何内存块——即使是泄漏的块——都不会与虚拟内存覆盖区域有任何关系，除非这个范围内的每个有用的内存块都可以重新分配到一个更紧凑的范围，这有点像Java或托管程序的垃圾收集机制，但对于大多数C/C++本地应用程序来说是绝对不可能的，因为在虚拟内存/[/k

至于本地代码，不必要的虚拟内存使用，这个实际问题，比未清理内存块的理论问题更实质。无人认领的内存块可能会导致虚拟内存的浪费和过多的系统开销，但也可能不会；这完全取决于堆管理器是否提交更多的虚拟内存来支持这种浪费。一些小的未使用的内存块不会导致不必要的堆扩展。不要让您猜测哪个或哪些浪费的内存块导致了堆扩展，而是要学习如何确定什么是有意义的浪费。当堆中包含未使用的内存块时，通过检查此时未减少的堆，可以确定与程序的虚拟内存需求有很大关系的必要的内存块清理。

为了找出堆中哪个内存块需要更多的关注，必须在程序中添加一些额外的代码来跟踪内存堆范围和分配的内存块。有条件地编译附加代码以生成特定版本可能是个好主意。

为了实现这个目标，有必要编写一个自定义的内存分配例程，并跟踪每个内存块，和另一个自定义的释放例程，并跟踪堆在虚拟内存中的位置。请参考例1和例2中的伪码算法。你可能还需要编写一个自定义的访问函数来标记被访问的内存块，以便在适当的时候释放虚拟内存，这些都不需要过多的内存开销。另一方面，如果你的程序以堆的形式使用大量内存，会大大降低性能，这里的方法也不是长久之计。

示例1:

/*输入参数*/
address trigger addr
size trigger size
list跟踪的堆范围的列表。

IF (triggerAddr处的虚拟内存作为堆范围的一部分在列表上被跟踪)
DO
IF(trigger addr+triggerSize >
(该堆范围的跟踪上限))
do
/*现有堆范围被扩展*/

进行系统调用，以确定包含从triggerAddr到(triggerAddr + triggerSize)的地址的新提交范围的基数和范围

跟踪的堆范围的更新大小，以指示其新的上限
end
end
else do
/*在triggerAddr */中有一个新的堆范围

进行系统调用，以确定包含从triggerAddr到(triggerAddr + triggerSize)的地址的新提交范围的基数和范围

在堆范围列表中跟踪新提交的范围
END

示例2:

/*输入参数*/
address trigger addr
size trigger size
list跟踪的堆范围的列表。

/*局部变量*/
地址origrangebase
大小origrangesize
boolbfundchange

bFoundChange = FALSE

如果(触发器addr处的虚拟内存没有在堆范围列表中作为堆范围的一部分被跟踪)
do
/*看来我们对这个版本已经很清楚了。*/
END
ELSE IF(读取triggerAddr处的内存时发生访问异常)
DO
bFoundChange = TRUE
END

IF (bFoundChange) DO
/*因为前一个内存块占用的空空间被释放，所以堆占用的虚拟内存范围发生了变化。*/

进行系统调用，以确定被跟踪的已提交堆范围的基址和范围，该范围紧邻已取消提交的范围，包括从triggerAddr到(triggerAddr + triggerSize)的地址

/*更新堆范围跟踪以反映剩余提交的范围*/

如果(包含TriggerAddr处的块的被跟踪堆范围的任何部分仍被提交)
DO
更新堆范围列表以仅跟踪该范围中保持提交的部分
END
ELSE
DO
删除跟踪范围的列表元素
END