Re: Jimple and bytecode length

[Ondrej Lhotak <olhotak@sable.mcgill.ca>]

I would probably go with the option 2 that you mentioned. You would
probably want to have one such N for each Jimple instruction, or even
add a method into Unit that would compute the N for each instruction.
Instructions like those that deal with the switch statement can have
variable length. I haven't heard of anyone else trying to do something
similar.

Ondrej

On Wed, Dec 11, 2002 at 11:09:52AM +1300, Stephen Cheng wrote:
> 
> When java bytecode is generated from Jimple instructions, the bytecode
> sequence may be too long and breaks the method code length limit specified
> by JVM spec (65535 bytes). I can writing a code transformer using Soot to
> add additional Jimple instructions to methods in a classfile. I need to make
> sure that the modified class file is still legal. Is there any easy way I
> can easily estimate the bytecode size of the method from the Jimple
> instructions?
> 
> I have thought of a few possible solutions, but none of them struck me as a
> good idea:
> 1. Get Soot to actually generate the bytecode sequence, and fail if the
> bytecode length exceeds limits. This approach is impractical in my
> application, as the transformation involves quite a few steps. It would be
> too expensive to generate the bytecode from the Jimple instructions after
> each step.
> 
> 2. Use a worse case estimate. Lets say we know a Jimple instruction can
> never generate more than N number of bytes of bytecode, then we can estimate
> the length of the bytecodes by using the multiplication factor. (What value
> is N?)
> 
> What do you think? Has anyone come across this problem before and what is
> your solution?
> 
> Thanks,
> Stephen
> 
>