You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Eugene Kuleshov <eu...@javatx.org> on 2006/01/03 16:19:34 UTC
Re: Javaflow and ASM
Kohsuke,
I've tried to run unit tests for asm transformer on code from SVN
and noticed that they all failing. I believe the reason is that you've
changed SimpleVerifier to BasicVerifier in the method analyzer and not
all of the checkcasts created with Object type. So, I am afraid that
we'll have to use SimpleVerifier to get the actual types of the stack
and local values.
Another possible approach could be to use results of
DataflowInterpeter to find an instructions that are consuming given
stack value and then cast to the type required by this instruction,
but I am not sure if there are some gaps in this approach, e.g. if
locals will cause issues...
regards,
Eugene
PS: I'll send a patch for local vars allocation later today.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Javaflow and ASM
Posted by Eugene Kuleshov <eu...@javatx.org>.
Kohsuke Kawaguchi wrote:
>> Actually your above example should be quite simple, especially if
>> we can assume that we know local variable types (e.g. debug
>> information is available):
>
> Well, sure, if you can use debug information, but I don't think we can
> assume that in javaflow, can we.
It depends. But in general you probably right. :-)
>> Though more complicated case would be the case when restoring stack
>> not directly used by the currently restoring method. Probably
>> something similar to what happening for NEW opcodes. And for this we
>> will have to always search for common super class or interface.
>
> OK, sounds like we are in agreement that we sometimes do need to compute
> the base class.
Right. BTW, SimpleVerifier is actually doing this already using
Class methods.
Though there is some tricky scenario that would be difficult to
handle. This is in case when two classes would have more then one
common interface (e.g. both implements Comparable and Externalizable)
and don't have common super class. Eric left a comment in
SimpleVerifier code about this scenario and I am not sure how this can
be resolved.
>>> It shouldn't be too difficult; BCEL does that. As I wrote in the
>>> commit message, all we need is a resolver that can get you the byte
>>> code image of those referenced classes (like ClassX and ClassY.)
>>
>> We have code for this within ASM test cases. It is in
>> MUSTANG_SUPPORT branch in org.objectweb.asm.ClassWriterTest3 class. If
>> you like I can try to put this code into SimpleVerifier subclass
>> already used in javaflow.
>
> That would be great.
Will do that and then depends from the results of your testing I
can look at implementing algorithm based on dataflow only.
regards,
Eugene
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Javaflow and ASM
Posted by Kohsuke Kawaguchi <ko...@sun.com>.
Eugene Kuleshov wrote:
> Actually your above example should be quite simple, especially if
> we can assume that we know local variable types (e.g. debug
> information is available):
Well, sure, if you can use debug information, but I don't think we can
assume that in javaflow, can we.
> Though more complicated case would be the case when restoring stack
> not directly used by the currently restoring method. Probably
> something similar to what happening for NEW opcodes. And for this we
> will have to always search for common super class or interface.
OK, sounds like we are in agreement that we sometimes do need to compute
the base class.
>> It shouldn't be too difficult; BCEL does that. As I wrote in the commit
>> message, all we need is a resolver that can get you the byte code image
>> of those referenced classes (like ClassX and ClassY.)
>
> We have code for this within ASM test cases. It is in
> MUSTANG_SUPPORT branch in org.objectweb.asm.ClassWriterTest3 class. If
> you like I can try to put this code into SimpleVerifier subclass
> already used in javaflow.
That would be great.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi@sun.com
Re: Javaflow and ASM
Posted by Eugene Kuleshov <eu...@javatx.org>.
Kohsuke Kawaguchi wrote:
>> Another possible approach could be to use results of
>> DataflowInterpeter to find an instructions that are consuming given
>> stack value and then cast to the type required by this instruction,
>> but I am not sure if there are some gaps in this approach, e.g. if
>> locals will cause issues...
>
> I don't think it's possible. The same variable maybe assigned to, say,
> java.lang.Comparable and java.io.Serializable. Consider the following code:
>
> SomeMiddleClass x;
> if(...)
> x = new ClassX();
> else
> x = new ClassY();
>
[1]
> someFunctionCall();
>
> if(...) {
[2]
> methodThatTakesSerializable(x);
> } else {
[3]
> methodThatTakesComparable(x);
> }
>
> Given that bytecode doesn't have the type for 'x', correctly restoring
> 'x' at someFunctionCall requires us to really find the common base type
> as described in the JVM spec.
Actually your above example should be quite simple, especially if
we can assume that we know local variable types (e.g. debug
information is available):
-- for [1] we have to cast restored variable x to SomeMiddleClass, for
-- for [2] we can cast method parameter (stack value) to Serializable
-- for [3] we can cast method parameter (stack value) to Comparable
Though more complicated case would be the case when restoring stack
not directly used by the currently restoring method. Probably
something similar to what happening for NEW opcodes. And for this we
will have to always search for common super class or interface.
In any case this approach should allow to eliminate second analysis
step and use only dataflow analyzer to move new opcodes and also to
find types of the stack and locals.
> It shouldn't be too difficult; BCEL does that. As I wrote in the commit
> message, all we need is a resolver that can get you the byte code image
> of those referenced classes (like ClassX and ClassY.)
We have code for this within ASM test cases. It is in
MUSTANG_SUPPORT branch in org.objectweb.asm.ClassWriterTest3 class. If
you like I can try to put this code into SimpleVerifier subclass
already used in javaflow.
regards,
Eugene
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Javaflow and ASM
Posted by Kohsuke Kawaguchi <ko...@sun.com>.
Eugene Kuleshov wrote:
> Kohsuke,
>
> I've tried to run unit tests for asm transformer on code from SVN
> and noticed that they all failing. I believe the reason is that you've
> changed SimpleVerifier to BasicVerifier in the method analyzer and not
> all of the checkcasts created with Object type. So, I am afraid that
> we'll have to use SimpleVerifier to get the actual types of the stack
> and local values.
OK. I'll roll it back to SimpleVerifier.
.... I guess your patch also fixed this. Thank you.
> Another possible approach could be to use results of
> DataflowInterpeter to find an instructions that are consuming given
> stack value and then cast to the type required by this instruction,
> but I am not sure if there are some gaps in this approach, e.g. if
> locals will cause issues...
I don't think it's possible. The same variable maybe assigned to, say,
java.lang.Comparable and java.io.Serializable. Consider the following code:
SomeMiddleClass x;
if(...)
x = new ClassX();
else
x = new ClassY();
someFunctionCall();
if(...) {
methodThatTakesSerializable(x);
} else {
methodThatTakesComparable(x);
}
Given that bytecode doesn't have the type for 'x', correctly restoring
'x' at someFunctionCall requires us to really find the common base type
as described in the JVM spec.
It shouldn't be too difficult; BCEL does that. As I wrote in the commit
message, all we need is a resolver that can get you the byte code image
of those referenced classes (like ClassX and ClassY.)
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi@sun.com