JIT在10k次调用之后进行方法优化(-XX:+PrintCompilation),您可以使用-XX:CompileThreshold进行配置。我读到了不降低此阈值的原因是JIT优化可能是错误的,或者您正在优化不经常使用的代码。我有几个关于这个领域的问题:
- 我认为错误的优化(即:on-stack-replacement)是由于多态方法的懒惰类加载导致的。但是在发现3个实现(我认为)之后,JVM只需执行索引表查找。当然,如果您有更多的多态实现,则速度会受到影响。多态方法是错误的JIT优化的唯一原因或主要原因吗?如果不是,还有其他原因吗?
- 如果我可以强制在启动时加载所有类,以便JVM可以预先构建这些索引表,那么总体优化是否更好?采用优化全部方法的方法有什么问题?如果我的目标仅是速度,那么成本是多少?
- 与C ++相比,如果我的源代码是封闭的,这意味着没有第三方库,就像低延迟系统一样,是否有一种方法可以强制进行预先优化,以使性能更接近C ++?
- Peter Lawrey在他的Oracle杂志文章中提到,您可以通过在生产中人为地运行足够的测试数据以满足阈值来启动JIT。这样做似乎在生产环境中很危险,一旦出现差错,您将被解雇。是否有更好的方法可以在最小风险的情况下完成?
- 非常感谢任何关于此主题(涉及Java和C ++)的良好参考资料。