current gcjx status

[Per Bothner]

Tom Tromey wrote:
> gcjx is a bit slow compared to other compilers, at the moment.

One performance bug, I think, in the current front-end is that
it reads too many classes.  I've tried improving the situation
with some experimental patches, but I haven't quite gotten it to
work because of inner classes.

If we're compiling A.java or A.class and A references class B, then
we may have to read B.java or B.class.  However, there is no need
to reference any class C referenced in B, unless C is part of the
interface of B referenced by A.  For example, no reference C in
the body of a method of B is interesting: We don't need to resolve
it or even see if the class C exists.  That will be done when we
compile B, so there is no point in doing it now while we're compiling A.

The exception is if we're doing javac-style "opportunistic compiling":
If the strategy is "I've had to read B and resolved its external interface;
might as well generate bytecode for it".

I don't know how well gcjx does in this respect - but jc1 seems
to be doing a very bad job.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/