Re: [abc] abc compiling itself

The problem is the class with the name:
CUP$Grm$actions

Based on the name, AbcClassSource concludes that it should be in the
source file CUP, but it isn't, so it loads it from a class file instead.

This whole thing about having $ in names in the source is very murky. I
don't really know exactly what the spec says, but different compilers do
very different things with it. Consider the file Foo.java:

public class Foo {
    class Bar {
        int thisOnesFromTheInnerClass;
    }
}
class Foo$Bar {
        int thisOnesFromTheTopLevelClass;
}

If you compile with javac, it complains about duplicate classes. If you
compile with jikes, it doesn't complain, and happily throws away the
top-level Foo$Bar.

Our question, I guess, is, if we get a reference to CUP$Grm$actions,
should we try to resolve it in CUP, or somewhere completely arbitrary
(like Grm)?

Now, something that would make this example work, but isn't a general
solution, would be this: currently, abc knows about which AST *some*
inner/local classes are in, but not all. So, we just chop off everything
after the $ and say that it should be in CUP. But, *in this case*, we do
have CUP$Grm$actions in our little table saying that it's in Grm. So,
we *could* just do both: check the little table with the original class
name, and the class name with everything after the $ removed. That would
work for this example, but wouldn't for an example in which abc doesn't
have the class in the table (such as if it were an anonymous class).

Given that this stuff isn't specified, I don't have a general solution.

Ondrej

On Fri, Sep 17, 2004 at 10:38:14AM -0400, Ondrej Lhotak wrote:
> On Fri, Sep 17, 2004 at 03:32:24PM +0100, Ganesh Sittampalam wrote:
> > Should we be setting -src-prec or some equivalent? I suspect we aren't...
>
> No, -src-prec just changes the list of ClassSources that Soot uses, but
> abc sets up its own list of ClassSources, so -src-prec will have no
> effect. It appears that AbcClassSource is broken on inner classes.
> It does seem to get Grm from .java, but Grm$actions goes from .class
> for some reason.
>
> Ondrej
>
> >
> > Ganesh
> >
> >
> > On Fri, 17 Sep 2004, Ondrej Lhotak wrote:
> >
> > > Sure enough, it's resolving everything from .class files! That's bad!
> > > Why is it doing that?
> > >
> > > Ondrej
> > >
> > > On Fri, Sep 17, 2004 at 10:19:20AM -0400, Ondrej Lhotak wrote:
> > > > I ran hprof on this, and 96% of the time is being spent on the type
> > > > assigner, being called on method(s) from .class file(s). This seems very
> > > > strange, because in this case, no .class files should be weavable! So,
> > > > something is very wrong.
> > > >
> > > > Ondrej
> > > >
> > > > On Fri, Sep 17, 2004 at 02:29:15PM +0100, Ganesh Sittampalam wrote:
> > > > > It seems that J2J may also have some problems with the huge method bodies
> > > > > in Grm.java; when I try the following, the worst culprit is
> > > > >
> > > > > Finished Jimplification in 354515 millisec.
> > > > >
> > > > > It then goes on to run out of memory in the phase after the Exceptions
> > > > > check, which I think is the soot packs, but first things first, I guess..
> > > > >
> > > > > CLASSPATH=$CLASSPATH:/usr/share/java/ant-1.6.jar:/usr/local/src/soot-dev/lib/jedd-runtime-0.2.jar java -Xmx512M abc.main.Main -verbose -debug timerTrace generated/abc/aspectj/parse/Grm.java
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Ganesh
> > > > >
> > > > >
> > >
> > >
> > >
> >
> >
Received on Fri Sep 17 16:03:54 2004