Examining performance on the JVM

[Bradbev]

I see lots of discussion on this list about Clojure performance & how
to get it to Java speed. I am also interested in the next steps that
happen, how does the JVM convert byte code down to machine code and
how does one examine that?
The profiling tools I use for C code let me look at what the compiler
has done with my C/C++ code & where the machine is running slow (cache
misses, pipeline stalls, etc).
JVM apps obviously have another layer of indirection, the first layer
is the quality of the byte code that has been generated, and then how
hotspot compiles that into machine code.
What tools are out there that let you examine the bytecode & JVM
machine code output? It would also be really nice if there were tools
that told you why the JVM did or did not manage to optimize a block of
code.

I'm just curious here really, but it does seem like there are many
knowledgeable people on this list that might be able to offer some
tips.

Thanks,
Brad

[Glen Stampoultzis]

Apparently it's possible to see the assembly instructions if you're running a debug VM [1].

-XX:+PrintOptoAssembly dumps to the console a log of all assembly being generated for JITed methods. The instructions are basically x86 assembly with a few Hotspot-specific instruction names that get replaced with hardware-specific instructions during the final assembly phase. In addition to the JITed assembly, this flag also shows how registers are being allocated, the probability of various branches being followed (along with multiple assembly blocks for the different paths), and information about calls back into the JVM.

[1] http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html

2009/7/16 Bradbev <brad.be...@gmail.com>

[Christian Vest Hansen]

I haven't tried to look beyond the JIT to see what it does, so I
wouldn't know which tools to use, but if you do not already know about
it, you might find the HotSpot Internals wiki to be an interesting
source of info: http://wikis.sun.com/display/HotSpotInternals/Home

--
Venlig hilsen / Kind regards,
Christian Vest Hansen.

[Daniel]

On Thu, Jul 16, 2009 at 11:00 AM, Glen Stampoultzis<gst...@gmail.com> wrote:
> Apparently it's possible to see the assembly instructions if you're running
> a debug VM [1].
>
> -XX:+PrintOptoAssembly dumps to the console a log of all assembly being
> generated for JITed methods. The instructions are basically x86 assembly
> with a few Hotspot-specific instruction names that get replaced with
> hardware-specific instructions during the final assembly phase. In addition
> to the JITed assembly, this flag also shows how registers are being
> allocated, the probability of various branches being followed (along with
> multiple assembly blocks for the different paths), and information about
> calls back into the JVM.
>
> [1] http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html
>

I don't have any concrete links right now but be sure to check the
slides (and videos) to JavaOne presentation of at least the last 3
years. Most of the time some of topics are presented at JavaOne in
specialized talks by engineers from CPU manufacturers. Not a lot of
Java developers would usually have the knowledge to go that deep down
to the metal, but it's very interesting to have someone from AMD or
Intel show you how to look at the JVM at that level. I remember that
there was an AMD talk one year where they showed an AMD (& Win) tool
to look into the CPU caches and registers, and how they used it to
pinpoint a synchronization problem that you wouldn't be able to find
with JVM level tools. Don't know about a specific talk, but Intel has
similar tools.

Also usually a great source of information are talks from Cliff Click
and other Azul people. Since they take the JVM-hardware combo to a
whole new level, they also have a lot of info on that layer.

Cheers,
Daniel

[Bradbev]

On Jul 16, 12:58 am, Christian Vest Hansen <karmazi...@gmail.com>
wrote:

Thanks to all the replies. Christian, the HotSpotInternals link is
great, thanks!

Brad

[Dimiter "malkia" Stanev]

Great question! I've been wondering the same, and I've found great
answers here.

But here is how I was able to get some of the assembly (in normal JVM,
not debug), but for small portions of code - for example this is how I
was able to see the point-in-poly algorithm.

Basically I put a tight loop around the computation, then attach with
debugger and almost 99% of the time it would be in the generated code.

I'm familiar with assembly language, although not very familiar with
the JVM calling conventions, register usage, etc. Still you can grasp
enough from there.

I'm also suprised how well JVM does (ahem, "java -server", not "java -
client").