Re: Re: Calculating Methods' Local Variable Sizes at Runtime

Nemo Caviani wrote:
> yes, using visitLocalVariable I am able to identify the set of 
> parameters passed to a method. 
  You don't need visitLocalVariable() at all
> What I can't figure out is how to get the actual values for these 
> parameters off the stack to calculate their real sizes. I can figure 
> out their names and their types from the method signature, and for the 
> primitive types a lookup table can give me the size of their memory 
> usage. What I don't know, is how to get the actual size of 
> non-primitive parameters. If the nonprimitive type contains an array 
> or a list, the length of the array or the list also size becomes a 
> critical factor in figuring out the amount of space it uses.
  You should really do your home work and at least search on Google. But 
here is the reference for you, it is a bit outdated and as  Godmar said 
it is expensive to do it that way, but it is a start. 
http://www.javaspecialists.eu/archive/Issue078.html
> so if you or anyone in the list can give me a clue on how to access 
> the actual value of a parameter from the local stack and calculate its 
> size, that would be a great help to me indeed.
  You will kinda have to learn some Java bytecode for that.
  A naive, brute force method could be like the following:
 
  Look at invokevirtual opcode. Documentation is here 
http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc6.html#invokevirtual.Operation

  At the visitMethodInsn(), the top of the stack will be like the following:
  ... , objectref, arg1, arg2, ... , argN
  so argN is at the top of the stack (1 or 2 words depending on its 
type), which you can get from the desc parameter of visitMethod(); then 
2nd parameter and so on, the last would be the object reference the 
method is called on.
  So, you've got the stack figured out, now for each method parameter 
you can create a new variable (for example, using LocalVariablesSorter 
or one of its subclasses described in the ASM User guide book) and store 
value off the stack into that variable using *store opcode corresponding 
to parameter type.
  After that for each non-primitive parameter you can load value from 
the variables you created and call your static helper method to figure 
out sizes.
  Once you done with that, all you'll have to do is to load values from 
those variables back into the stack, so invokevirtual instruction will 
get the same stack as before your transformation.

  There is some difference in handling invokevirtual, invokespecial, 
invokestatic and invokeinterface instructions.

  Obviously the above solution is suboptimal and can be heavily 
optimized, e.g. to not create unnecessary variables in trivial cases 
with 1 to 4 method parameters and for primitive parameters, e.g. using 
stack manipulation bytecode instructions, but I will leave this exercise 
for you.
 
  regards,
  Eugene

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws