[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: Javaflow and ASM
From:       Eugene Kuleshov <eu () javatx ! org>
Date:       2005-12-31 21:05:16
Message-ID: 43B6F28C.50907 () javatx ! org
[Download RAW message or body]

Kohsuke Kawaguchi wrote:

>>> - When moving 'new' instructions, local variables are allocated 
>>> excessively. I think it would be better for it to be used little more 
>>> conservatively. Namely, the number of additional local variables for 
>>> save/restore should be max of all constructor parameter counts, not 
>>> sum of them.
>>
>>    I spotted this too and tried to fix this but haven't completed yet. 
>> It seems that instead of using MethodNode.maxLocals as a 
>> stackRecorderVar its value should be memorized and vars for param 
>> restoration should be always started from that value + 1
> 
> Yes.

   Can you carry on this or would prefer a patch from me?

>>> - When moving 'new' instructions, The maxStacks  field isn't updated 
>>> correctly, but I think we needed this.
>>
>>    It will be recalculated automatically when ClassWriter is used with 
>> computeMaxs
> 
> Hmm. I got "insufficient stack size" error or something like that when I 
> didn't do anything. I added maxStack += 10 for a try and that made it 
> work, which made me suspect of this issue.

   That could be a error from analyzer. If so, we may not get away 
without fixing maxstack or will have to run a complete stack computation 
algorithm.

>>> - While instrumenting the FinallyFlow class, I found that 
>>> ContinuationMethodAdapter.visitMethodInsn dies while trying to save a 
>>> local variable that has a JSR return address in it. I don't think we 
>>> can instrument method invocations in a finally block, so there needs 
>>> to be code that checks it (I don't know how BCEL version is doing 
>>> that, though)
>>
>>    Another option could be to inline these blocks. I believe that one 
>> of the projects, which been using ASM did that already and we can just 
>> reuse it. I actually was thinking to package it with the asm-commons 
>> or something.
> 
> That sounds like a good idea. 

   That is why I've added Eric to this discussion. So, we can find an 
acceptable way to integrate this feature.

 > With such code where the same set of byte
 > code is copied into multiple places, would it still be possible for a
 > user to set a breakpoint and etc correctly?

   As of breakpoints, they are working based on line number information 
and because code is basically identical we can just copy this info to 
both places. BTW Java6 and CLDC preverifier both doing this for finally 
blocks bytecode.
   It is actually interesting. The same line number can be referenced 
from several places in the bytecode and finally blocks are not the only 
case for this. If I recall correctly the same also happens for the loop 
constructs as well as for constructor and static initializers.

   regards,
   Eugene


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]