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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
