Question on getting started with ASM JVM bytecode

[Michael Nitschinger]

Hi Everyone,

I'm following this group now for a while and I want to learn more about this stuff and get my hands dirty a bit. I'm using Mac OS X, but I managed to get the hsdis dylib running and eventually some ASM output.

Now, the most simplest program I came up with is of course:

public class Main {
 public static void main(String[] args) {}
}

Now, when I run it with

javac Main.java && java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly Main

I get an output like this (gist because its very long): https://gist.github.com/daschl/5848839

While I understand that there must be something going on, I wonder why there are so many String#hashCode calls in there? (nearly 30)..

My other question is that if you guys know some "tricks" to actually make it easy to mark/spot some code that I'm interested in debugging.. like if I put an algorithm into a method, how can I easily identify that method ans spot where my code is actually supposed to run?

Any input or initial help would be greatly appreciated (and may be of help to newcomers). To contribute back, I'll write up a blog post on how get this up and running on Mac OS X, since I didnt find lots of material on the web either.

Cheers,

Michael

[Michał Warecki]

Hi!

There are no calls but lines in one (or two) hashCode call. Look:

java.lang.String::hashCode@1 (line *1446*)
java.lang.String::hashCode@6 (line *1447*)
...

Michał

2013/6/24 Michael Nitschinger <mic...@nitschinger.at>

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael Nitschinger]

Hey, thanks for your reply, but I'm not sure if I can follow quite :)

So is the #hashCode method being executed once or more down the stack? My question was mainly by whom and why! Also, maybe I'm guessing something wrong here and the actual bytecode has been optimized into something that looks quite different than my code fragment that would explain this.

2013/6/24 Michael Nitschinger <mic...@nitschinger.at>

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Michał Warecki]

I'm not 100% sure but in this case *your* code hasn't been even assembled (because there is no code in main method). JVM is not required to assemble the whole code. It will assemble only the most used and the most "interesting" parts. Try to put some code and run it 15000 times in a loop.

String#hashCode has been called by JVM itself. Why? I don't know - that's private JVM matter :-)

Michał

2013/6/24 Michael Nitschinger <mic...@nitschinger.at>

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Michael Nitschinger]

Jeah I did a few tests and I think when debugging this, it really pays off to have small and more or less decoupled methods and classes (which is good coding practice anyway). 

Because you'll get a ASM block for each decompiled method, which makes it much easer to track.

Is there any tool available that makes it "easier" to browse such asm code? Like get the ~op cycles per op and maybe see some dependencies? I guess I need to eyeball parse it anyway, but I wonder if there are tools that make it easier to code-debug-code-debug.

2013/6/24 Michael Nitschinger <mic...@nitschinger.at>

2013/6/24 Michael Nitschinger <mic...@nitschinger.at>

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscribe...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael Nitschinger]

As promised, there you go - short and sweet: http://nitschinger.at/Printing-JVM-generated-Assembler-on-Mac-OS-X

[Gil Tene]

AFAIK there is nothing that highlights assembly code by op cycles in regular HotSpot. But Zing's ZVision does exactly that, and I use it to read generated code all the time. See example output in my Jan 3 posting on the "CMOVcc v. Jcc (probably one for Gil)". I always try to read assembly code in the profiler (after making it hot enough) because it makes it much easier to read. Most generated method code usually has tons of hard to read code that does nothing (deals with setup and with edge conditions and never actually run). Identifying [with confidence] the code you actually want to understand within a method can get to be pretty hard. 

When you read the code with profiler CPU% annotations, like Zing provides in ZVision, you immediately focus on the code that actually runs, and thereby only need to understand and decipher the code that actually matters. I find that this easily saves me 80% of the assembly deciphering time and increases my certainty that I know what code to look at.