java JIT什么时候有错误的优化？

Question

JIT在10k调用后进行方法优化（-XX：+ PrintCompilation），您可以使用-XX：CompileThreshold进行配置。我读到了不降低阈值的原因是JIT优化可能是错误的，或者您优化了不经常使用的代码。关于这方面，我有几个问题：

1. 我认为错误的优化（即：on-stack-replacement）是由于多态方法的惰性类加载。但是在找到3个实现（我认为）之后，JVM只进行索引表查找。当然，如果你有更多的多态impl，速度会受到影响。多态方法是错误JIT优化的唯一原因还是主要原因？如果没有，其他人是什么？
2. 如果我可以强制加载astartup中的所有类，那么JVM可以预先构建这样的索引表，是不是更好地预先进行整体优化？优化所有方法有什么问题？如果我的目标只是速度，那么成本是多少？
3. 与C ++相比，如果我的源是关闭的，这意味着没有第三方库，就像那个低延迟系统一样，是否有办法强制优化，以提高性能，使其更接近c ++？
4. Peter Lawrey在他的oracle杂志文章中提到，你可以通过在生产中人工运行足够的测试数据来达到阈值，从而启动JIT。这样做在生产环境中似乎很危险，一次事故就会被解雇。必须有一个更好的方法来做到最小风险。
5. 非常感谢任何有关此主题的好参考（涉及java和c ++）。

更新：＃3。永远不要期望java比c ++更快，只想更接近。

Answer 1

  

有没有办法强制优化，以提高性能   要比c ++好吗？

不。这是Java规范中强制执行的语义的基本限制，以及JVM生态系统的工作方式，它将比C ++实现慢，假设实现和代码的质量相当。有关详细信息，请查看my existing answer on this subject。