JITted code support

JITted code support

Does SDE have support for dynamically JITted code such as from a Java JVM?

15 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

yes, sde supports JITs.

SDE is built in pin. Pin has two mechanisms for handling self modifying code. If the default does not work, i believe there is an advanced knob that costs more at runtime but catches more cases. Ususally the default is fine though.

I am a newbie at this, but I am trying the following:

sde -mix -- java -version

Where java.exe is a 64-bit executable on my path.

sde/pin seems to want to execute a 32-bit java.exe whereas if I just type java on the command line I get a 64-bit JVM. If I explicitly put the full pathname to the 64-bit jvm on the sde command line, it just returns with no output.

What am I doing wrong?

Never saw that kind of thing before. I just confirmed that on my system (below). Looks like you found a bug. Thanks for reporting this issue.

% sdekit/sde -- java -version
java version "1.6.0_24"
Java SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot Client VM (build 19.1-b02, mixed mode, sharing)
% java -version
java version "1.6.0_24"
Java SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot 64-Bit Server VM (build 19.1-b02, mixed mode)

Seems like if you give the full path to java.exe, it will run the right version (64b) version. I'm looking in to what is going on there and why the path-search is picking up the 32b version when the 64b version is on the path. I think it may have something to do with the binary being "mixed mode" and sde internally starting the 32b version of pin first. Normally pin would then start 64b pin if it detects a 64b user app, but this mixed mode thing might be confusing it. I don't know yet.

% path-to-kit/sde -- "C:/Program Files/Java/jre6/bin/java.exe" -version
java version "1.6.0_24"
Java SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot 64-Bit Server VM (build 19.1-b02, mixed mode)

I spoke with some colleagues who know windows better than I and they informed this this is a feature of windows. Java install puts a 32b version in the system32 directory. For unqualified application names, SDE/Pin uses the official windows search algorithm wihch searches app directory, current directory, system directory then the PATH. So when you don't specify the path, you end up running the one from the system directory. (Being a linux guy, I was a little surprised by this.) Hope this helps.


For some reason when I run sde and give the full path to the 64-bit executable, it doesn't run (no error reported, just no output).

By the way, this java.exe is a normal 64-bit executable. "mixed mode" here just means the JVM uses a combination of interpreted and compiled (JIT) code (it is possible to start the jvm in fully interpreted mode or fully compiled mode).

Being more of an arch guy, i initially thought mixed mode meant 32b/64b. But yes, you are right. MSDN educated me too :-)

I am not sure why you are not seeing any output. Are you running from a cmd.exe? Or using cygwin?

This is from cmd.exe

I decided to try on linux (SLES11-SP2). This seems to be a very different issue.

# /root/java/6u29/bin/java -version
java version "1.6.0_29"
Java SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot 64-Bit Server VM (build 20.4-b02, mixed mode)

# ./sde -- /root/java/6u29/bin/java -version
C:Tool (or Pin) caused signal 7 at PC 0x7f59a438cf66
C:Location may be in in-lined analysis code, try re-running with '-inline 0' to debug itBus error

what is the syntax for adding -inline 0 ?

Sorry you are having difficulties. What version of sde are you running? 4.29? Show the output of "sde --version"

About your linux issue:
path-to-sde/sde -p -inline -p 0 -- yourapp
The "-inline 0" mesage is coming from pin and to pass args to pin you need to prefix EACH one with -p. Let me know what you find. I tried the public SDE 4.29 on SLES10 with java and it worked for me. My java version is lightly different. I also tried the latest java for linux on ubuntu10.
% sde-hsw-external-4.29.0-2011-06-23-lin-intel64-and-ia32/sde -- /usr/intel/pkgs/java/ -version
java version "1.6.0_25"
Java SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot 64-Bit Server VM (build 20.0-b11, mixed mode)
% sde-hsw-external-4.29.0-2011-06-23-lin-intel64-and-ia32/sde -- jre1.6.0_29/bin/java -version
java version "1.6.0_29"
Java SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot 64-Bit Server VM (build 20.4-b02, mixed mode)
For linux, can you run sde on anything? Like hello world or /bin/ls?
About your windows issue:
I am not sure why you are not seeing output. I could not reproduce that with the SDE kit I presume you are using (4.29) on windows 7 in a cmd.exe. Maybe there is something about your PATH that is confusing things?
Can you run sde on anything? like a hello world app?

OK, I had been using 2.94 which someone here recommended but I updated to 4.29 and things seems to work now on Linux with the Hotspot JVM. (2.94 worked with the IBM JVM but not with Hotspot). So things are looking better.

One thing I did notice with running java which produced actual JIT compiled code is that when it goes to display the disassembled code in a top block, this works fine with Hotspot but not with the IBM JVM. There is shows up as


Do you think this has something to do with the way the different JVMs map the code pages?

If I understand your question properly...

In the current version that you have there is a knob -disas-at-jit which refers to the JIT processing that Pin does while processing the application. Ironically, this knob is for user apps like java which are also JITs. JITs create code and reclaim it during execution, reusing the storage. The normal mix report assumes that all the code is still present at program-end time when we generate the output report. But for JITs this is not true. So for JITs we currently require that users use the -disas-at-jit knob with -mix to cause the disassembly to be done at Pin's JIT time which is when the code is guaranteed to exist. The overhead is higher for the -disas-at-jit mode because we must disassemble everything, hot or not. We cannot know what is hot at JIT time.
We are looking at internal optimizations that change how mix works and removes that overhead and the knob entirely.
Let me know.

Tried it and it solved the problem on the IBM JVM. That's a good switch to have. I wonder why it was necessary on IBM and not on Hotspot. I don't think either one actually reuses the JITted code storage for something else, but maybe by program end, the IBM JVM has deallocated that memory or something.

Thanks for your help!

Leave a Comment

Please sign in to add a comment. Not a member? Join today