I would like to see the current (bytecode) instruction stream of the JVM it is executing. After some googleing, I found that the jvm debug build offers the -XX:+TraceBytecodesoption (see here). However, the mentioned link to the hotspot JVM debug build is dead and I could not find a debug build online :/
Is there another way to trace the jvm bytecode stream or can someone point me in the right direction? I'm running 64 bit ubuntu 16.04.
P.S: I know, its going to be painfully slow to print out the complete instruction stream. However, I am curios
-XX:+TraceBytecodes option is exactly what are you looking for. It is available in debug builds of HotSpot JVM. You can easily build JVM yourself - just HotSpot, not even JDK.
Clone hotspot repository from OpenJDK 8 project
hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot
Build 'fastdebug' JVM (assuming JDK is already installed at /usr/java/jdk1.8.0_102)
cd hotspot/make
make ALT_BOOTDIR=/usr/java/jdk1.8.0_102 ARCH_DATA_MODEL=64 fastdebug
You may add HOTSPOT_BUILD_JOBS=N to run compilation in N parallel processes.
Run it
export ALT_JAVA_HOME=/usr/java/jdk1.8.0_102
../build/linux/linux_amd64_compiler2/fastdebug/hotspot -XX:+TraceBytecodes MainClass
can someone point me in the right direction
Well I'll try. The only thing I've found is using jdb. You'll have to create your own "printer".
Because you're asking this out of curiosity rather than need, I don't think you'll go as far as creatinf an application that does what yout want, but maybe you'll find other ressources that does it (I didn't find any) or at last ease the job .
From what I understand, jdb (java debugger) is a CLI program that uses the JDBA (Java Platform Debugger Architecture) and JVM TI (Java Virtual Machine Tooling Interface).
This is a how jdb works:
You compile your code with the -g option (not mandatory), start your main class with jdb (rather than java).
You can do step by step execution of your code using step command in the console, but this might run multiple bytecode instructions (all the ones corresponding to the instruction in the source code)
You can use stepi which only executes one bytecode line.
You must set a breakpoint to do step by step execution, and the cont option will go to the next breakpoint (just like in a IDE).
The list option allows you to see the code around your breakpoint/line (but not the bytecode).
You can also get the current line number in source file, and in bytecode (with wherei, I think).
The other tool is javap -c to get readable bytecode (but I think you already knew this).
Now with all these, I guess you see where I'm going. You create an application (java applicaiton, or some shell/dos) that uses jdb to do step by step bytecode execution, and you pick the matching line in your bytecode from javac -p to print it. Note that I don't know how you should do in multi-threaded environnements. There are also bytecode visualisation tools like ASM or dirtyJOE, but I don't think they offer bytecode debugging option.
I believe the JVM TI is used by IDE's debuggers, and might be more powerfull faster, and complex than jdb.
Some links that might interest you:
How to debug bytecode
Basic debugging with jdb
Jdb commands list
Java debugger platform architecture
As for myself, I was also curious on how java debuging (and other stuff) worked, so this was kinda interesting.
Related
Hm, so I set up Scala in order to start learning it.
When I compile a .scala script, though (i.e. "scala whatever.scala" in the terminal), java.exe is accessing the internet?
Why? Is that intended behaviour or did I forget to configure something?
The script I run was fairly simple, if that should matter:
args.forall(println)
It seems to me that Scala compilation happens inside a Java JVM. So when you compile Scala, the java command is executed.
Java JRE has a mecanism to update itself. When a new version is out, it asks the users (at least on windows?) if they want to install the new version.
It is possible that everytime a java command is launched, it checks for updates (?)
Edit: it is possible that this is because in some cases you are using a "compile server" for Scala. This means an extra JVM is spawned just for compilation and is kept alive after your initial compilation. Then next compilation will be faster because the compilation server will already have been started and all the classes will be loaded.
It is possible that a client JVM is communicating to the compilation server JVM by using a network protocol.
Check some links:
http://blog.jetbrains.com/scala/2012/12/28/a-new-way-to-compile/
https://github.com/typesafehub/zinc
Running: Mac OS X 10.8.5
I'm following the step by step instructions on the Greenfoot website:
http://www.greenfoot.org/doc/kinect/macos.html
I've dealt with all the run arounds with installing Macports for OSX 10.8, and finally installed 'boost', but for the final part, at the bottom of the site I attempt to type the code in terminal at the proper directory to configure it:
./configure --with-boost=/opt/local/include --with-wx-config=/opt/local/bin/wx-config --with-wx-prefix=/opt/local
This is what it gives me and stops at this certain point. It goes through all it's configuring and stops here:
checking for the Boost thread library... no
configure: error: cannot find the flags to link with Boost thread
I've also instead tried to install boost 1.49 instead of boost 1.50(the latest) but no luck there.
Any suggestions?
Same error on Mac OS X 10.9 - from the m4/boost.m4 file from the kinectserver-1.2 directory:
Now let's try to find the library. The algorithm is as follows: first look
for a given library name according to the user's PREFERRED-RT-OPT. For each
library name, we prefer to use the ones that carry the tag (toolset name).
Each library is searched through the various standard paths were Boost is
usually installed. If we can't find the standard variants, we try to
enforce -mt (for instance on MacOSX, libboost_threads.dylib doesn't exist
but there's -obviously- libboost_threads-mt.dylib).
So if there's a convenient way to tweak the source to point to "libboost_threads-mt.dylib" as the target for the "checking for the Boost thread library..." step, that would appear to be the ticket - still looking at what to tweak to accomplish this, though.
My java application which uses JNI is crashing with hs_err_pid file giving the error as "Exception Access Violation". The OS is Windows VISTA.
From what I know, my native code is illegally writing to some chunk of memory that does not belong to it.
I have used valgrind on Linux on pure native code to detect such problems in the past.
But when using java, valgrind simply fails and does not work.
What (if any) method would you suggest to identify the offending piece of code?
It is not possible for me to manually dig through the native code (few million lines) to identify it.
I was finally able to resolve the issue. I thought I will post the procedure here in case someone else is in a similar situation.
Step 1:
Build the native code with proper debugging symbols. The compiler flags could be something like "-g -rdynamic -O0".
Step 2:
The following valgrind command should do the job.
valgrind --error-limit=no --trace-children=yes --smc-check=all --leak-check=full --track-origins=yes -v $JAVA -XX:UseSSE=0 -Djava.compiler=NONE $JAVA_ARGS
In the above command, $JAVA is the java executable and $JAVA_ARGS is the arguments to your java program.
Once successfully started, it will take orders of magnitude more time to complete the execution. Valgrind will print thousands of errors (most related to jvm which can be ignored). You can however identify the ones that relate to your jni code.
This general strategy should be applicable to most native memory related problems.
If you are running Java under Linux, you could use the -XX:OnError="gdb - %p" option to run gdb when the error occurs. See this example.
Under windows, you can use the -XX:+UseOSErrorReporting option to obtain a similar effect.
For debugging JNI code a method posted in this article could be useful (it's about debugging JNI using Netbeans and Visual Studio). It's simple - just start your Java program, then in Visual Studio pick Debug -> Attach to process and choose java.exe process running your program.
When you add breakpoints to your C++ code, Visual Studio will break on them. Voila :)
I've tried following the advice found # https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly and http://alexshabanov.com/2011/12/29/print-assembly-for-java/ , but it wasn't of much help. I'm running a 64bit JVM on Windows7, and I've put the suggested hsdis-i386.dll file in all folders there's a jvm.dll, just to be sure.
I seem to have several JVM installations (at least I have one in C:\Program Files (x86)\Java and other in C:\Program Files\Java), so I don't know whether this is making any difference. From what I've seen, doing a java -d32 yields an error, so I must be using the 64bits version one only.
When trying to run
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -server -cp . HelloWorldApp
only my
Hello World!
message is shown, so nothing seems to be happening. Maybe the problem is that hsdis-i386.dll should have other name?
Btw, I'd like to stay away from having to build any kind of source files myself.
Hotspot won't begin compiling and optimizing until it knows what is important, and when you run such a short program it doesn't have the opportunity to kick in. Give it something more substantial.
I just installed Java Developer on Windows Vista. The installation process looked OK and it was successfuly finished. However, I do not know how I cun run this program? Nothing new on the desctop appeared?
First of all it is important to note that the Java Development Kit (JDK) is not a GUI tools such as Visual Studio. It consists mainly of pure command-line tools used to compile, run and debug Java code.
There are IDEs (Integrated Development Environment) which provide the entire Editor/Compiler/Build-System integrated in one big setup, but in my opinion the very first steps should be done with the pure JDK.
Start with this intial Java tutorial.
Generally The Really Big Index should keep you occupied for quite some time.
Fetch yourself a development environment like Eclipse: http://www.eclipse.org/ and start playing around.
The JDK is just that: a software development kit, sitting around in a directory specified by you and waiting for you to invoke its command line tools ...
If by "Java Developer" you mean the Java Development Kit (JDK), then you "run" it via the command line - use javac to compile and java or javaw to run the compiled classes.
If you mean you installed the JDK—the Java development kit—then this is just the Java compiler and the sources of the class library (roughly). You can then go ahead, create Java programs in any text editor and compile them.
But you probably want an IDE, such as Eclipse.
Go to Command Prompt. In the command prompt go to the directory where the Java program is located. In the command line type "java name_of_the_program.java". It will generate name_of_the_program.class. After that you can type (in the command line) "javac name_of_the_program" and the program will be executed.
It is how it should be in theory. But in practice it will not work. To make it work you have to find your java-directory (a directory where "javac.exe" is located). In my case it was "C:\Program Files\Java\jdk1.6.0_18". Then you have to create 4 new environment variables (classpath, include, lib, path) and set them to be equal to the name of the above mentioned directory. After that you need to restart your computer and after that will be able to compile your progam (by typing "javac name_of_the_program.java").
But of couse it is not the end of the story. If you type "java name_of_the_program" the program will not be executed. Java will write you that it is cannot find the main class. How to solve this problem I do not know yet.