JVM JIT诊断工具和优化提示 [英] JVM JIT diagnostic tools and optimization tips

问题描述

我听到很多关于JVM JITs可以做什么的信息，但没有看到关于如何配置JIT实际执行的信息的很多信息。有很多关于使用 -XX：+ PrintCompilation 和 -XX：+ PrintOptoAssembly 的提示，但结果非常低难以理解的级别信息。

一般来说，在优化期间，我喜欢有一套基准测试套件以及专用的JIT预热时间等等，但是，我希望能够看到哪些优化实际上正在触发我的代码。也许我的JVM考虑内联一个特定的方法调用，但有些事情使它决定不要，或者也许JIT无法避免在我的循环中进行数组边界检查，因为我措辞不变和循环条件太模糊。我希望像YourKit这样的工具能够支持某种形式的JIT发生了什么，但我一直无法在YourKit或其他任何地方找到它的支持。

理想情况下，我只是喜欢JIT的优化器在运行我的程序时想的东西。假设我已经预热了我的功能，并且决定将三种方法内联到我的内部循环中，并将循环分成三部分，在中间部分没有数组边界检查，我希望总结这些决定和动机对于他们来说。

我在这里错过了一些明显的东西吗？ JVM性能感知型编程人员在优化紧密内部循环以确定发生了什么时会执行什么操作？低级 -XX 标志肯定不是唯一的选择，他们可以吗？我很高兴提示如何在JVM上处理这种低级别的东西。不，这个问题不是过早优化的动机！ ：）

编辑：我想我想要的一些是由 -XX：+ LogCompilation 给出的，如果人们有这种活动的一般提示和工具，那么m仍然很好奇。

如果你想要大脑转储，你可以打印生成的汇编代码，但这比您已经拥有的级别要低很多。我怀疑HotSpot JVM不存在您正在查找的内容。我看到了一个基于JRockit的演示文稿，也许这会在一天内将其加入到HotSpot中。

我在这里错过了些什么？ JVM性能感知型编程人员在优化紧密内部循环以确定发生了什么时会执行什么操作？

通常，我喜欢将垃圾产生量降到最低，而且这通常表现得不错。例如微秒潜伏期。

这种微型优化确实需要深入理解机器代码以及CPU如何真正起作用。

当然，低级-XX标志不可能是唯一的选择，它们可以吗？

只要它那么简单，它就复杂得多。要转储机器码，您需要一个附加的本机库，它不随JVM提供。 ;）

我很高兴提示如何在JVM上处理这种低级别的东西。

如果您可以避免这种情况，您似乎并不想在低级别工作，我相信这是一件好事，您必须首先考虑高级别，因为微型优化对于微型基准测试非常有用，但对于实际应用程序来说很少有用，因为您需要了解端到端系统的所有延迟，而且您甚至可以不用考虑在许多情况下的代码。即是数据库，操作系统，磁盘或网络IO的主要延迟。

我仍然很好奇人们是否有一般的技巧和这种活动的工具。

使用一个分析器，如果你怀疑你需要降低，很可能你有错过了更重要的事情。

I hear a lot about what JVM JITs can do, but don't see a lot of information on how to profile what the JIT is actually doing in a given run of your program. There are lots of tips about using -XX:+PrintCompilation and -XX:+PrintOptoAssembly but it results in really low-level information that is hard to interpret.

In general, during optimization, I like to have a benchmark suite of common operations with dedicated JIT warmup time and so on, but I'd like to be able to see which optimizations are actually firing on my code. Perhaps my JVM considered inlining a particular method call but something about it made it decide not to, or perhaps the JIT was unable to avoid array bounds checks in my loops because I phrased my invariants and looping conditions too obscurely. I'd expect a tool like YourKit to support some form of "what is going on with the JIT" but I haven't been able to find support for that in YourKit or anywhere else.

Ideally I'd just like a brain dump of what the JIT's optimizer is thinking during a run of my program. Say I've warmed up my function plenty and it decided to inline three methods into my inner loop and broke the loop up into three sections with no array bounds checks on the middle section, I'd like a summary of those decisions and the motivation for them.

Am I missing something obvious here? What do JVM performance-aware programmers do when optimizing tight inner loops to figure out what is going on? Surely the low-level -XX flags can't be the only option, can they? I'd appreciate hints on how best to deal with this sort of low-level stuff on the JVM. And no, this question is not motivated by premature optimization! :)

Edit: I guess some of what I want is given by -XX:+LogCompilation but I'm still curious if people have general tips and tools for this kind of activity.

解决方案

If you want a brain dump, you can print the resulting assembly code, but this is much lower level than what you have already. I suspect what you are looking for doesn't exist for the HotSpot JVM. I saw a presentation for something like this based on JRockit and perhaps this will make it into HotSpot one day.

Am I missing something obvious here? What do JVM performance-aware programmers do when optimizing tight inner loops to figure out what is going on?

Usually, I like to minimise garbage production and this usually performs well enough. e.g for micro-seconds latencies.

This sort of micro-optimisation really requires a deep understand of machine code and how CPUs really work.

Surely the low-level -XX flags can't be the only option, can they?

If only it where that simple, it is far more complicated. To dump the machine code you need an additional native library which doesn't ship with the JVM. ;)

I'd appreciate hints on how best to deal with this sort of low-level stuff on the JVM.

It appears you don't really want to work at the low level if you can avoid it and I believe this is a good thing, you have to take care of the high level first because micro-optimisation is good for micro-benchmarks but rarely good for real applications because you need to understand all the latencies of your end to end system and this you can do without even looking at the code in many cases. i.e. is the main delay in your database, OS, disk, or network IO.

I'm still curious if people have general tips and tools for this kind of activity.

Use a profiler, and if you suspect you need to go lower, it is quite likely you have missed something far more important.

这篇关于JVM JIT诊断工具和优化提示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！