Well, yeah, stack traces aren't going to tell you what you say you need to know. That's because stack traces tell you things about your Java code. But that isn't what you say you want. You say you want to know what memory locations in the compiled version of the Java byte-code are executed.
At least that's what you say. I can't imagine why you need to know that or what you plan to do with it -- especially since the volume of output is going to be enormous. If you have a 1 gigabyte processor, that means that your machine can execute 1 billion operations per second. So the debugging you say you want is going to output 1 billion pieces of information every second. And those billion pieces of information aren't going to be very useful either -- what can you do with something which says "Executed the instruction at location 3055802"?
As you might have guessed, I don't think that is really what you need to know. Or perhaps I misunderstood what you were asking. Perhaps you could go back a step and describe the problem you are trying to solve with this unique debugging technique?
Joined: Aug 24, 2012
Jelle Klap wrote:As of Java 5 there's the JVMTI if you want to create a native application that communicates with a JVM.
I'm not quite sure that's what you're after, though.
I'm basically developing a code coverage tool. So I thought of using the PC's values to perform code coverage.