增量式存储碎片收集
增量式存储碎片收集(incremental garbage collection)比关联存储碎片收集更加复杂。尽管现在有几种不同的实现方式都声称是增量式存储碎片收集，但事实上这是多年来悬而未决的问题。下面描述增量式存储碎片收集的一种特定的实现方式。
考虑在“来源”和“目的”区域上运行的一个去碎片存储碎片收集器(关联型或者非关联型)。随着存储碎片收集的进行，“来源”区域中的全部有效对象都会移到“目的”区域。复制过程由索引遍历来驱动。每一个索引都采取以下的处理方式：如果目标对象还没有被复制，那么就复制该目标对象，并且将其索引添加到要处理的索引列表中。最初的索引都要重新改写以反映对象的新位置，并且指向目标对象新位置的一个前向地址会保留在那个对象最初的“来源位置”处。当所有索引的对象都已经被复制，并且所有的索引都已经重新改写，那么存储碎片收集(那一个区域的)就结束，并且“来源”区域可以重新使用。
www.55dianzi.com
增量式 存储 碎片收集 通常采取突发、短时运行方式。在这些突发的运行之间，允许用户线程运行，这样就可以减少等待时间。当然，在用户线程执行之前，存储碎片收集器并不能够保证对一个对象的所有索引都进行合适的重新改写。那么当索引仅仅修正了一半的时候，程序怎样才能准确无误地继续运行？答案同样也在于写屏蔽。
当程序试图对存储器进行写操作时，系统会进行检查，以确保被写入的对象是否正在被存储碎片收集器移走。如果是这样，那么写操作就会在旧的位置和新的位置同时进行。这样的技术避免了“读屏蔽”的必要性，同时也保证借助于没有被修正的索引，所作的修改不会被丢失。
聪明的读者会注意到：对象索引的集合在突发的存储碎片收集之间可能会改变。去掉索引应该没有什么坏处。存储碎片收集器已经标示出：一个对象是有效对象移去之后这个对象最后的索引，那么该对象肯定可以在下一次的存储碎片收集过程中收集起来。
然而必须小心处理索引的增加。存储碎片收集进程“正在处理”的过程中，每一次存储一个新的索引时，当存储碎片收集继续执行时，必须将该索引添加到需要处理的索引列表中。同样写屏蔽也要确保这一过程将工作正常。
在增量式存储碎片收集过程中，关于新对象的创建也有其它巧妙的细节。这些对象必须小心地分配在一个独立的区域中，存储碎片收集结束后，该区域将成为新产生对象的存储区域。如果能让这些新对象立即参与当前的存储碎片收集过程，那么它们就可以迅速升级。而采用其它方法，它们则会错过最开始的机会，并且没有机会存储在新产生对象的存储空间中，并通过关联存储碎片收集器来进行快速收集。
新的问题
通过上面所有的讨论，存储碎片收集听上去比实际情况更直观。系统执行应用程序代码需要花费的时间总量，以及执行存储碎片收集的时间总量之间存在某种精细的平衡。如果系统需要花费太多的时间去实施存储碎片收集，那么数据吞吐量就会受到影响。如果系统花费太多的时间去执行应用程序代码，那么存储碎片收集器就不能进一步运行下去，最终导致应用程序必须等待完整的存储碎片收集完成，所以最坏情况下，滞后问题可能得不到解决，当然这种情况极为稀少。
由于存储碎片收集器上的负载随应用行为而变化，因此仅仅调节存储碎片收集的静态参数不太可能达到较好的平衡。要切实解决这一问题，存储碎片收集子系统需要动态地监视其自身与应用的相对情况。应用分配了多少存储器？存储器从新产生对象存储区域到主要存储区域之间的升级有多快？存储碎片收集正在顺利进行还是已经滞后？如果已经滞后，那么应该怎么办？需要更加频繁地实施关联存储碎片收集或者将对象在新产生对象存储区域中保持更长的时间吗？在哪一个特定时刻必须实施一轮完整的存储碎片收集，以确保所有存储器在消耗光之前有时间来完成这一过程？
关键的一点是“协调步伐”以确保存储碎片收集器总是在应用程序之前，避免最终可能产生的所有滞后，并且获得真正的实时性和确定型的行为。当然，通常这都取决于应用行为良好这样的假定，也就是说，这些应用并不会非常快速地分配和释放存储空间，从而导致存储碎片收集器不能协调工作。在那种情况下，因为没有足够的存储空间可以使用，会导致存储碎片收集器需要花时间来释放存储器。需要多少缓冲器取决于存储碎片收集器的效率以及最坏情况下应用的行为。提高关联存储碎片收集的效率，就减少了需要获得实时性能所必须的缓冲器总数。
讨论如何达到这样的一种奇迹超出了本文的范畴。一个优秀的存储碎片收集器应该能够体现许多关于内部的信息。
存储碎片收集器的评价
在评价系统性能时，存储器使用以及存储碎片收集的开销是关键的一个统计量。许多存储碎片收集器都提供一种测量API来查询存储空间的创建、收集、以及从新产生对象存储空间到主要存储器空间升级的比率。跟踪应用随时间的行为的能力，对于进一步的性能调整很有价值。
对性能进一步调整的工具通常关注测量对象创建和撤销的比率。高明的程序员通常都知道如何通过重写代码打乱对象次序来极大地提高速度。我们有一个Java程序需要将几千个时间信息(长总数)转换为字符串。有一种标准的Java类型方法可以一步实现这种转换，但是在它内部创建(并且丢弃)了一个“日期格式化程序”对象。将根据步长重新替换高级运算，就能够得到一种准确的日期格式化程序对象。这样就节省了用于创建(以及存储碎片收集)几千个日期格式化程序对象所需要的时间。
有时候应用程序知道什么时候会被闲置，这是通知存储碎片收集器启动一个完整的存储碎片收集的最好时机。要做到这一点就需要利用一个控制API来影响存储碎片收集器的行为。然而，从前面的讨论中可以了解到，存储碎片收集器通常都比较清楚什么时候应该清理这些存储碎片。
本文小结
一般来说，存储碎片收集以及特殊情况下的关联存储碎片收集已经成为近年来人们不断研究的课题。关联存储碎片收集最先出现在桌面应用环境中。比如Sun的HotSpot JVM就是采用关联存储碎片收集。增量式存储碎片收集由于减少了等待时间，所以通常在 嵌入式 领域应用更多。HotSpot也可以进行增量式存储碎片收集，但是时间增量非常大，在桌面应用中存储碎片收集的进展被认为比等待时间更重要。
关联存储碎片收集在性能上提升了一个数量级。它极大地提高了增量式存储碎片收集的效率。嵌入式应用开发人员会发现，综合运用增量式存储碎片收集以及关联存储碎片收集会得到最好的存储碎片收集效果，也可以调整等待时间以适合响应时间的要求。
本文关键字：嵌入式 嵌入式系统-技术，单片机-工控设备 - 嵌入式系统-技术
上一篇：嵌入式系统支柱学科的交叉与融合
