Java execution details in System.out

Question

As I remember there is a magic command line option in Java that turn on writing of operations that are currently executed to console. The output was looked like byte code.

-verbose does not match as it prints only class loading, while this option outputs information like memory allocation, setting local variables etc. It was very detailed, like 10 lines for "Hello world".

I did not find it neither here http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp nor here http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html Also I have found some flags here, but most of them work only in openjdk or in the develop mode. Maybe there is a way I can start java.exe on Windows in this develop mode? Or maybe there is another set of flags that this lists miss?

Answer 1

Not quite what you asked, but I'm a big fan of "kill -3" on the java process id - that dumps out all sorts of information about every thread and what state they are in, what locks they hold and what locks they are waiting on, and that sort of thing.

Answer 2

On windows use Ctrl-Break to create a thread dump. To monitor classloading use -verbose:class for garbage collection -verbose:gc

Answer 3

Supported options here. The closest I can find to your description is -verbose:gc, or perhaps -verbose:class.

javap will output bytecode, but it's a static disassembler, and not related to runtime.

Answer 4

I've been using jvisualvm quite a bit recently; maybe that would give you what you want? It does profiling of both memory and CPU use, can dump thread stacks, and can even persuade the JVM to list what classloader activity is going on (via the MBean support: go to java.lang→ClassLoading, select Attributes and update Verbose; it still dumps to System.out of course). The great thing about this is that you don't need to anything to enable it (normally); you can just attach to already running JVMs. (If you've got Java 1.5, use jconsole instead.)

Note however that you're unlikely to get a dump of what bytecodes are executed. This is because the HotSpot JIT engine – which has been around for a fair few years now – converts the bytecodes to native instructions before execution so by the time the code is actually executed, there's simply no bytecodes left for the instrumentation to report on. Theoretically you might be able to build a special VM that worked in the old way, but it would be horribly slow (like the bad old days) so why would you really want to?