我有一个关于我对Rust Borrow的理解的基本问题，相对于JVM的垃圾收集器。如果这是一个业余的问题，我道歉。
我试图深入了解Java中的各种垃圾收集实现（如G1和CMS）是如何工作的。我还试图浏览this resource来了解Borrow函数实际上是如何帮助Rust决定何时释放内存的。
下面是上面链接的Rust资源的一部分：
Next, we perform a number of dataflow analyses that compute what data is moved and when.
We then do a second type check across the MIR: the purpose of this type check is to determine all of the constraints between different regions.
Next, we do region inference, which computes the values of each region — basically, the points in the control-flow graph where each lifetime must be valid according to the constraints we collected.
At this point, we can compute the "borrows in scope" at each point.字符串
我从根本上不明白的是，在整个“GC语言因为停止世界而对性能很糟糕”的论点中，为什么这样的东西不能在JVM中实现？
理论上/可证明的是，是否不可能执行上面列出的相同步骤（dataflow analyses that compute what data is moved and when）来决定何时主动释放内存，而不是我们目前在JVM中使用的基于暂停的实现？
1条答案
按热度按时间2admgd591#
我认为这是不可能的-类似于解决停机问题-但事实上，这并不重要。
事实上，完美是好的敌人。JVM已经很容易执行 Escape Analysis，它允许它优化不需要对象的对象的分配。例如，具有两个
int字段的Point结构可以优化为堆栈上的两个int值。这里所指的数据流分析在JVM中是现有逃逸分析的变体或补充分析，有时候会有所帮助。
然而Java会成为障碍。Rust * 语言 * 从一开始就在拥有的值和引用/指针之间进行了明确的划分，因此数据流分析也是有区别的。Java语言没有这种区别，因此任何对值的跟踪都要复杂得多，最终成果也要少得多。
最后，不要忘记Rust还提供了
Rc/Arc：引用计数指针，用于静态作用域不足以表达应用程序逻辑的情况。Java/JVM也需要一些这样的动态机制。GC就是这样一种机制。