问题标签 [escape-analysis]

这是我试图从Java Performance: The Definitive Guide, Page 97关于Escape Analysis主题复制的示例。这可能是应该发生的事情：

1. getSum()必须变得足够热，并且必须使用适当的 JVM 参数将其内联到调用者main()中。
2. 由于list和sum变量都不会从main()方法中逃脱，它们可以被标记为NoEscape因此 JVM 可以为它们使用堆栈分配而不是堆分配。

但是我通过jitwatch运行它，结果显示它getSum()编译成本地程序集并且没有内联到main(). 更不用说因此堆栈分配也没有发生。

我在这里做错了什么？（我已经把整个代码和热点日志放在这里了。）

这是代码：

我使用的JVM参数：

我最近一直在尝试了解 JVM 逃逸分析。根据这个不错的答案，我尝试了很多 JVM 选项的组合。我的问题是，这些选项值是否有任何硬性限制？像FreqInlineSize， MaxInlineLevel。当我将选项设置为一些荒谬的值时，JVM 不会认真对待它， -XX:FreqInlineSize=65535会这样吗？事实上，我试过了。但是jvm并没有抱怨。所以我真的说不出来。

如果有一些硬性限制，那会是什么？我在哪里可以找到描述这些事情的文件？

我一直在尝试找到一种方法来强制将我的 Protobuf 消息和构建器对象分配到堆栈而不是堆上。有时它会起作用。但是当消息对象的字段数量增加时，它就停止了工作。我在互联网上搜索了很多，但由于我对这个主题的了解有限，我几乎没有发现任何结果。所以这就是我问的原因。

JVM 版本：Java HotSpot(TM) 64 位服务器 VM（内部版本 25.131-b11，混合模式）

尝试检查go程序中的局部变量是否分配在堆或堆栈上，并且无法确定go的gc的某些输出的含义。

代码

variable_heap_stack.go：

执行：

运行 -gcflags -m variable_heap_stack.go

输出：

问题

• 是什么escapes to heap意思？它会堆积还是不堆积？
• moved to heap，这意味着移动到堆，对吧？和上面的有什么区别？
• 变量是本地的y，函数返回后没有人引用它，但仍然有一行y escapes to heap，这是为什么？

我想知道 Clang 或 GCC 中是否有任何优化选项可用于std::vectorC++ 中的转义分析。因为std::vector<int>在下面的示例中，不需要v在堆或堆栈中分配实际数据。编译器实际上可以在堆栈上分配v.data()以获得更好的性能。

1. 假设 Clang/GCC 不做逃逸分析，是否有什么特别的动机不使用逃逸分析？

2. 假设 Clang/GCC 进行了逃逸分析，为什么 value ofv.data()和&x这么不同？

预期结果

Clang 和 GCC 的实际结果

谢谢！

HotSpot Java 9-13 的堆栈分配优化规则是否不那么严格？

在 Java 7 和 Java 8 HotSpot 对象堆栈分配（由于称为标量对象替换的 JVM 优化）是可能的，但要在线程堆栈上实现无垃圾分配，必须满足许多严格的约束。

为 Java 8（HotSpot、OpenJDK 8）启用堆栈分配优化的规则总结在对这个问题的精彩回答中： Hotspot 什么时候可以在堆栈上分配对象？ 至于这里的 Java 7： Eligibility for escape analysis / stack allocation with Java 7

在这个问题中，我想了解更新 JDK 版本中 EA 和堆栈分配优化的当前状态是什么？其他 Java VM（例如 OpenJ9）是否有不同的规则？

我的代码在这里=>

使用 jitwatch，我可以看到 pointHolder 没有被分配，但new Point(x+2, 42)仍然被分配。

我不知道为什么

关于此代码的问题。为什么变量逃逸到堆

gorun -gcflags "-m -l" main.go

我发现如果使用fmt.Sprintf它也会导致变量逃逸到堆

我不太明白为什么 Go 的转义分析说，当传递fmt.Fprintln给与fmt.Fprintln. 我希望下面的两个场景 A 和 B 应该让问题更清楚。

场景A：x逃逸到堆
取如下内容main.go：

现在运行时，go build -gcflags "-m"您会看到指示x逃逸到堆的输出。输出说明了一些类似的内容

场景B：x不逃到堆
现在取以下内容main.go：

再次运行go build -gcflags "-m"，您会看到一个输出，表明x不再逃逸到堆中。输出现在说了一些类似的东西

我不明白这里的区别。我会认为场景 A 是正确的，因为x它被传递给一个接受任意数量interface{}参数的可变参数函数。但显然这是错误的，因为变量在传递给自写函数时不再转义，该函数myOwnPrintFunction也是一个接受任意数量interface{}参数的可变参数函数，编译器被指示不要内联这个简单的函数。

我们正在尝试优化 JS 代码在移动设备上的启动时间并寻找机会。我发现Facebook Hermes JS 引擎是为类似目的而创建的，但目前我们严重依赖 V8。

是否可以使用 V8 完成构建时预编译，这意味着解析和代码优化将在编译时完成并在运行时节省一些时间？从源代码生成 LLVM 位码并在运行时执行位码似乎非常接近我的想象。WASM 似乎不是一种选择（至少对于移动设备而言）。

如果可能的话，能否提供一个用 V8 优化的简单 JS 代码的简单示例？

PS。可能它也有助于内存消耗，这可能是次要目标。

假设我有一个想要循环的 java.util.Collection。通常我会这样做：

但是假设这是在一些到处使用的核心实用方法中，并且在大多数地方，集合是空的。那么理想情况下，我们不希望仅仅为了执行无操作循环而对每个调用者施加迭代器分配，我们可以重写如下：

如果是一个列表，一个更极端的选择things是使用 C 风格的for循环。

但是等等，Java 转义分析应该消除这种分配，至少在 C2 编译器使用这种方法之后。所以应该不需要这种“纳米优化”。（我什至不会用微优化这个词来形容它；它有点太小了。）除了......

我一直听说逃逸分析是“脆弱的”，但似乎没有人谈论过什么特别能把它搞砸。直觉上，我认为更复杂的控制流将是主要担心的事情，这意味着应该可靠地消除 for-each 循环中的迭代器，因为控制流很简单。

这里的标准反应是尝试进行实验，但除非我知道其中的变量，否则很难相信我可能会从这样的实验中得出的任何结论。

事实上，这是一篇博客文章，有人尝试过这样的实验，但 3 个分析器中有 2 个给出了错误的结果：

http://psy-lob-saw.blogspot.com/2014/12/the-escape-of-arraylistiterator.html

与那篇博文的作者相比，我对晦涩难懂的 JVM 魔法的了解要少得多，而且很可能更容易被误导。