Re: [javaflow] Need help in fixing a problem in javaflow

[Torsten Curdt <tc...@vafer.org>]

Hey Raji,

thanks for bringing this to the list

I think the sketch in section 2.4 in
http://vafer.org/pub/papers/spasm.pdf gives a general overview of code
rewriting.

As long as the method that is being called is instrumented properly
you should be able to make this work - with some changes necessary
though. Without looking into the current javaflow code I would think
that javaflow would need to also "record" reflection based calls to
methods (not just straight native method calls). So judging from your
code snippet you are on the right track there. Sorry, I can't be of
much more help at this time.

You can do it! ;)

cheers,
Torsten

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

Re: [javaflow] Need help in fixing a problem in javaflow

[Torsten Curdt <tc...@vafer.org>]

Hey Raji,

thanks for the update!

> I have fixed this for a specific scenario., i.e., in a specific scenario
> where the class/method and object variables are local variables and I have
> modified my code where I need a reflection continue to have the variables
> as local variables.
>
> For now, I had to do a few things I do not like, it is a hack. But I am
> able to get it to work consistently for any of the methods I have
> instrumented. Will come back and do a better job of it.

That would be great!

> Attached the changes I have done. This also includes changes I had to do to
> port javaflow to asm 4.0_RC2, changes to consider different classloaders to
> resolve objects in the same stack trace.

You would have to open a issue for this. Mailinglists and attachments
- not so good.
Please also be aware that trunk recently was updated to ASM 4 already.

cheers,
Torsten

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

Re: [javaflow] Need help in fixing a problem in javaflow

[Raji Sankar <rs...@gmail.com>]

Hi,

An update on this:

I have fixed this for a specific scenario., i.e., in a specific scenario
where the class/method and object variables are local variables and I have
modified my code where I need a reflection continue to have the variables
as local variables.

For now, I had to do a few things I do not like, it is a hack. But I am
able to get it to work consistently for any of the methods I have
instrumented. Will come back and do a better job of it.

In general I have followed the same guideline as I have outlined below..,
except I had to do a few more things:
1) when the class is analyzed, I have fixed to recognize the variables that
form the parameters for the java/lang/reflect/Method calls and store this
as a part of the method
2) when the java/lang/reflect/Method is popped out I setup the parameters
as the parameters I detected instead of null which is what is passed
currently
3) I need to pop out the calling object reference also.
4) Currently I have only enabled this on the existence of an annotation
ContinueReflection

Attached the changes I have done. This also includes changes I had to do to
port javaflow to asm 4.0_RC2, changes to consider different classloaders to
resolve objects in the same stack trace.

Thanx
Rgds
Raji .S.


On Sun, Jul 1, 2012 at 10:59 PM, Torsten Curdt <tc...@vafer.org> wrote:

> Hey Raji,
>
> thanks for bringing this to the list
>
> I think the sketch in section 2.4 in
> http://vafer.org/pub/papers/spasm.pdf gives a general overview of code
> rewriting.
>
> As long as the method that is being called is instrumented properly
> you should be able to make this work - with some changes necessary
> though. Without looking into the current javaflow code I would think
> that javaflow would need to also "record" reflection based calls to
> methods (not just straight native method calls). So judging from your
> code snippet you are on the right track there. Sorry, I can't be of
> much more help at this time.
>
> You can do it! ;)
>
> cheers,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>