JVM中的确定性垃圾回收

Question

我想知道热点JVM或其他JVM是否可以确定性地进行垃圾回收。我知道逃逸分析，但不确定它是否也适用于堆分配的对象。我的意思是，在C++代码中，像这样的代码可以在堆上提供确定性垃圾回收。

#include <vector>
int main(int argc, char*argv[]){
    std::vector<double> v_somevector;
} // std::vector::~vector() is called determinitically

在Java中肯定有类似的东西

.
.
.
private double ma() throws Exception{
    double result = 0.0;
    final double[] closes = new double[100000];
    //perform some calculation using the closes array above
    return result;
} // At this point why shouldn't closes be deterministically garbage collected (as in immediately)?

在垃圾回收最接近的数组时应该是确定性的。似乎逃逸分析似乎侧重于在堆栈上分配最接近的数组的可能性，但即使在堆上分配，在这种情况下，我也不明白为什么不能在离开ma（）范围时收集它。

- Michael

Answer 1

它可能是可以的；Java规范并没有禁止它。它只是完全由实现来决定垃圾回收的问题。事实上，JVM甚至不必实现垃圾回收！原因很简单，JVM有许多技术可以使用，这些技术在概率上比您所提到的同步分配更加高效，例如分代堆和并发标记-清除。您可以自由地在自己的VM中实现您所说的逻辑，但性能分析已经证明，对于许多业务类型的工作负载，C++程序中大部分CPU使用率都用于对象的构建和销毁，而像分代堆这样的方法可以简化很多内存管理。

- chrylis -cautiouslyoptimistic-

---

我已经成功地编写了许多应用程序，几周内没有因为 Full GC 而暂停，但仍然认为可能有某些情况下不希望推迟 GC。因此，将其作为 VM 选项可能是一个好的选择。 - Michael

请注意，同步的、引用计数的内存管理也可能会导致突然的延迟，例如如果堆过于分散需要进行一些整理，或者如果您释放对一个大型链表/二叉树的引用，从而导致许多引用同时达到零。 - Marko Topolnik

Answer 2

您所说的并不是那么确定的垃圾回收，而是急切的垃圾回收。如果JVM真的给您这样的体验，您会后悔自己的选择。急切的垃圾回收在回收和分配两个方面都很低效：它强制运行时以过于细粒度的方式处理内存，排除了许多优化机会，并导致堆碎片化。

如果您真的关心性能，那么您希望进行全面的GC清理，而这正是HotSpot所做的。

- Marko Topolnik

Answer 3

我记得几年前引入了JRockit实时JDK。不确定它是否符合当前的规格。

PDF演示

- chro