嵌入式系统设计中的存储碎片收集策略

新的问题


通过上面所有的讨论，存储碎片收集听上去比实际情况更直观。系统执行应用程序代码需要花费的时间总量，以及执行存储碎片收集的时间总量之间存在某种精细的平衡。如果系统需要花费太多的时间去实施存储碎片收集，那么数据吞吐量就会受到影响。如果系统花费太多的时间去执行应用程序代码，那么存储碎片收集器就不能进一步运行下去，最终导致应用程序必须等待完整的存储碎片收集完成，所以最坏情况下，滞后问题可能得不到解决，当然这种情况极为稀少。


由于存储碎片收集器上的负载随应用行为而变化，因此仅仅调节存储碎片收集的静态参数不太可能达到较好的平衡。要切实解决这一问题，存储碎片收集子系统需要动态地监视其自身与应用的相对情况。应用分配了多少存储器？存储器从新产生对象存储区域到主要存储区域之间的升级有多快？存储碎片收集正在顺利进行还是已经滞后？如果已经滞后，那么应该怎么办？需要更加频繁地实施关联存储碎片收集或者将对象在新产生对象存储区域中保持更长的时间吗？在哪一个特定时刻必须实施一轮完整的存储碎片收集，以确保所有存储器在消耗光之前有时间来完成这一过程？


关键的一点是"协调步伐"以确保存储碎片收集器总是在应用程序之前，避免最终可能产生的所有滞后，并且获得真正的实时性和确定型的行为。当然，通常这都取决于应用行为良好这样的假定，也就是说，这些应用并不会非常快速地分配和释放存储空间，从而导致存储碎片收集器不能协调工作。在那种情况下，因为没有足够的存储空间可以使用，会导致存储碎片收集器需要花时间来释放存储器。需要多少缓冲器取决于存储碎片收集器的效率以及最坏情况下应用的行为。提高关联存储碎片收集的效率，就减少了需要获得实时性能所必须的缓冲器总数。


讨论如何达到这样的一种奇迹超出了本文的范畴。一个优秀的存储碎片收集器应该能够体现许多关于内部的信息。


存储碎片收集器的评价


在评价系统性能时，存储器使用以及存储碎片收集的开销是关键的一个统计量。许多存储碎片收集器都提供一种测量API来查询存储空间的创建、收集、以及从新产生对象存储空间到主要存储器空间升级的比率。跟踪应用随时间的行为的能力，对于进一步的性能调整很有价值。


对性能进一步调整的工具通常关注测量对象创建和撤销的比率。高明的程序员通常都知道如何通过重写代码打乱对象次序来极大地提高速度。我们有一个Java程序需要将几千个时间信息(长总数)转换为字符串。有一种标准的Java类型方法可以一步实现这种转换，但是在它内部创建(并且丢弃)了一个"日期格式化程序"对象。将根据步长重新替换高级运算，就能够得到一种准确的日期格式化程序对象。这样就节省了用于创建(以及存储碎片收集)几千个日期格式化程序对象所需要的时间。


有时候应用程序知道什么时候会被闲置，这是通知存储碎片收集器启动一个完整的存储碎片收集的最好时机。要做到这一点就需要利用一个控制API来影响存储碎片收集器的行为。然而，从前面的讨论中可以了解到，存储碎片收集器通常都比较清楚什么时候应该清理这些存储碎片。


本文小结


一般来说，存储碎片收集以及特殊情况下的关联存储碎片收集已经成为近年来人们不断研究的课题。关联存储碎片收集最先出现在桌面应用环境中。比如Sun的HotSpot JVM就是采用关联存储碎片收集。增量式存储碎片收集由于减少了等待时间，所以通常在嵌入式领域应用更多。HotSpot也可以进行增量式存储碎片收集，但是时间增量非常大，在桌面应用中存储碎片收集的进展被认为比等待时间更重要。


关联存储碎片收集在性能上提升了一个数量级。它极大地提高了增量式存储碎片收集的效率。嵌入式应用开发人员会发现，综合运用增量式存储碎片收集以及关联存储碎片收集会得到最好的存储碎片收集效果，也可以调整等待时间以适合响应时间的要求。