Stack and local variables in bytecode tracing

[Tom Rodriguez]

There are some helpers in frame.hpp for looking at interpreter frames  
though I don't know if they work correctly inside the bytecode tracer.

The extra bytecodes are used internally to either implement faster  
special case versions of existing bytecodes or to implement other  
pieces of Java semantics.  Our internal bytecode iterator normally  
hides their existence.

tom

On Feb 23, 2009, at 6:06 PM, Peng Du wrote:

> Hello, everyone
>
> I know there is a BytecodeTracer class which is only enabled in  
> DEBUG build, which is used to spit out bytecodes when the  
> TraceBytecodes option is turned on. What I am interested in are the  
> addresses to java heap being accessed (read/write) when the opcodes,  
> e.g. aload, astore, putfield, etc, are executed.
>
> However, by default this method does not print out  those kind of  
> information even in verbose mode AFAIK. So, I want to modify the  
> class by adding a new method whose solely purpose is when a memory  
> access code is in execution, extract the memory addresses, either  
> from the expression stack (for xxstore), or from the local variable  
> pool (for xxload).
>
> I know tos, tos2 are passed directly to the BytecodeTracer::trace()  
> method. But for array opcodes, e.g. aastore, there are three  
> elements on stack, i.e. arrayref, index, value. If "value" is tos,  
> how can I get arrayref?
>
> Furthermore, what are the correct ways to peek on the expression  
> stack and in local variable pool?
>
>
> My another question is: in bytecodes.hpp, there are two groups of  
> bytecodes, ie. Java bytecodes and JVM bytecodes. I understand what  
> Java bytecodes are. But what are JVM bytecodes (_fast_XX)?
>
>
> Thanks in advance.
>
>
>
>
>
> Peng Du
>