JVisualVM reports that I’m generating megabytes worth of iterators every frame. This is bothering because there are other things I’d rather have room to create megabytes of every frame. However I’ve heard anecdotally that it is only the presence of JVisualVM’s profiling that actually causes these iterators to be picked up because it turns off the escape analysis feature in the JVM.
Could the assembled hive mind prove one way or the other that this is indeed happening (who’s got a debug VM handy to print the assembly out)?
You don’t need a debug VM, just the disasm DLL (which Oracle can’t distribute). I posted a link at some point, but am unable to find it with a search (and don’t have a copy ATM)
EDIT: Oh the file is ‘hsdis-amd64.dll’ and probably someone has a copy.
Are you in a position to try / use Java Mission Control? According to various things I’ve read, including the article you linked to, this can analyse without switching off escape analysis.
Stop wasting your time with traditional profilers. Treat them like antivirus software; they lie all the time and they are not made to help you. Yes, they’re that bad.
This is true, merely the presence of an attached profiler will disable escape analysis and many other optimizations. The simplest way to identify whether EA is kicking in or not is to use JITWatch. It’s my favorite performance analysis tool these days. It doesn’t require a debug VM or the disasm DLL (though disasm is highly recommended for low-level tuning). Here’s a demo of the EA reporting:
LK1Ain1JDlQ
A debug VM will tell you why a particular allocation has not been eliminated. This is useful, but not critical for performance tuning, assuming you’re familiar with the basics. Once you identify a problematic allocation, it takes a bit of refactoring to solve the problem and it’s rarely an unfixable situation. Like everything else in Java, bytecode size, call depth and associated inlining decisions play the most critical role.
