[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: resolveConcreteDispatch() and resolveAbstractDispatch()
On Fri, Apr 26, 2002 at 02:26:44PM +0100, Stephen Cheng wrote:
> > However, I don't see the VM spec specify this anywhere. Also, I can't
> > imagine even a non-Java compiler ever producing such bytecode.
> The behaviour is actually defined in the JVM Specification section on
> InvokeVirtual. The possible permutations of method overshadowing and the
> resultant behaviour are really mind-boggling. However even though that the
> classes file cannot be generated by the JavaC they are still legal. The
> class files pass the verifier and therefore must be correctly processed by
> Soot, if Soot aspires to be the compiler-independent experimental platform.
I stand corrected. This should be fixed.
> If there is a chance that the method call would fail to resolve to a
> concrete method in run-time, resolveXxxDispatch() must return a result as
> such, to stop dependent analysis wrongly relying on the result.
Noted.
> I am halfway through a first pass analysis of the VTA and CHA implementation
> and here is my list of observations. As I am still relatively new to Soot no
> doubt some of these comments are biased by my expectations ;-) so please
> correct me:
Thank you for pointing these out. I will accept patches to fix them.
I will try to fix them myself if time allows.
> 2. resolveAbstractDispatch() trips up on abstract classes implementing an
> interface. When resolveAbstractDispatch() is called to resolve a method of
> an interface, it collects the set of classes implementing the interface,
> including those classes that are abstract. It will then call
> resolveConcreteDispatch() on every single of these classes. However
> resolveConcreteDispatch() fails on partially implemented abstract classes
> and it will throw an exception if the method in question is not actually
> implemented. This bug trips up whole-program optimisation on JDK 1.4.0
> rt.jar.
This should be a one-line fix, no? If nobody disagrees with the
following, I will apply it.
--- Hierarchy.java.old Fri Apr 26 10:15:25 2002
+++ Hierarchy.java Fri Apr 26 10:19:56 2002
@@ -499,8 +499,11 @@
ArraySet s = new ArraySet();
- while (classesIt.hasNext())
- s.add(resolveConcreteDispatch((SootClass)classesIt.next(), m));
+ while (classesIt.hasNext()) {
+ SootClass cl = (SootClass) classesIt.next();
+ if( Modifier.isAbstract( cl.getModifiers() ) ) continue;
+ s.add(resolveConcreteDispatch(cl, m));
+ }
List l = new ArrayList(); l.addAll(s);
return Collections.unmodifiableList(l);
> 5. VTA relies on VTANativeAdjuster. VTANativeAdjuster appears to code
> additional method call relationships between a native method caller and a
> callee method. IMO this as an unsound design since VTANativeAdjuster is
> highly dependent on a particular implementation of the java library.
I believe the current VTANativeAdjuster is for the 1.1 library. In
theory, users of other libraries could plug in their own native adjuster
for their own library. In the medium term (end of summer), we are
working on a very flexible replacement for VTANativeAdjuster, and
updating it to new libraries.
> 6. VTA analysis relies on the reachability analysis (see MethodCallGraph) to
> calculate the reaching types. However I do not believe reachability analysis
> is producing the full set of reachable methods under every circumstances, as
> it is using a fixed set of entry methods (see MethodCallGraph.initialise()).
MethodCallGraph.initialise() should probably call some abstract method
to add in entry points. The user could implement this method to reflect
his or her environment.
> In fact until the set of entry methods is exposed to the
> command-line, we cannot do VTA based analysis/optimisations on J2ME, RTJ,
> and any J2SE applications that employs serialisation/RMI.
Exposing it on the command line is another alternative. I think
implementing an abstract method is more flexible.
> I think we need to do quite a lot of work before whole program optimisation
> reaches production quality. I hope this post helps getting us there. I like
> the basic architecture of Soot, and I thank you Sable people for a work well
> done.
I would be interested in finding out what you are using Soot for.
Ondrej
> Regards,
> Stephen Cheng
>
>