Re: Instrumentation + BCEL | ASM
- From: Piotr Kobzda <pikob@xxxxxxxxx>
- Date: Thu, 08 Jun 2006 23:57:36 +0200
Boris Gorjan wrote:
Piotr Kobzda wrote:
[snip]
This is another problem
I have another one, too. Namely, using your code I can't transform methods
1. which don't have any arguments (verifier says
java.lang.VerifyError: (class: path/to/TimingTest, method: test
signature: ()V) Illegal local variable number) )
and
2. methods with $ in their names (like access$0) -> inner classes? (verifier says java.lang.VerifyError: (class: path/to/TimingTest,
method: access$0 signature: (Lpath/to/TimingTest;)V) Illegal local
variable number)
Could you look into that, please?
It seems to me you have incorrectly computed max locals value for your methods. Have you set computeMaxs option in your ClassWriter?
My code (with ASM 2.1) transforms perfect all kind of methods in my tests (synthetic, parameterized etc.).
There is thousand possible reasons of your code malfunction, but first of all ensure you are not fighting with some bugs of ASM beta 3, so if you haven't done it yet, switch to the stable ASM version.
Another thing: my (first ;-) ) effort of detecting already modified mehods failed miserably. I added another visit method into MethodAdapter:
public void visitMethodInsn(
final int opcode,
final String owner,
final String aName,
final String aDesc
) { super.visitMethodInsn(opcode, owner, aName, desc);
if(
owner.equals("path/to/MyTiming)
&& (
aName.equals("start")
|| aName.equals("end)
)
) {
throw new RuntimeException(name + desc
+ " already contains timing calls. Aborting.");
}
}
Strangely enough, with this method added, I can only transform methods with exactly one argument of type String). For all others a transformed class fails verification.
Very strange... And I have no concept what's the reason of that, show a little more code.
Any suggestions?
After reading this and your previous post I think, that you don't have to care about existing start() and end() calls within your code.
Similar problem exist for example in a case of recursive calls, your start() method will be called many times before end(). And it should be YourTiming start() and end() methods implementation responsibility to treat such a scenarios well.
You said before that there is some kind of stack-trace computed in your implementation, so having it in a calls to end() you can find out which start() this call is related to (simply ignoring all unrecognized end() calls). This needs some kind of method calls stack reflected in your implementation but will give your users a freedom of choices.
Moreover, you will no longer need end() taking a String parameter in this scenario, because you can assume that each end() call is always related to the last start() call (parameterized or not) performed in the same level of method calls stack.
Hope that's clear. :)
Regards,
piotr
.
- Follow-Ups:
- Re: Instrumentation + BCEL | ASM
- From: Boris Gorjan
- Re: Instrumentation + BCEL | ASM
- References:
- Instrumentation + BCEL | ASM
- From: Boris Gorjan
- Re: Instrumentation + BCEL | ASM
- From: Piotr Kobzda
- Re: Instrumentation + BCEL | ASM
- From: Boris Gorjan
- Re: Instrumentation + BCEL | ASM
- From: Piotr Kobzda
- Re: Instrumentation + BCEL | ASM
- From: Boris Gorjan
- Re: Instrumentation + BCEL | ASM
- From: Piotr Kobzda
- Re: Instrumentation + BCEL | ASM
- From: Boris Gorjan
- Instrumentation + BCEL | ASM
- Prev by Date: socket problem, how to reconnect without restart
- Next by Date: Java date formatting
- Previous by thread: Re: Instrumentation + BCEL | ASM
- Next by thread: Re: Instrumentation + BCEL | ASM
- Index(es):
Relevant Pages
|