current gcjx status

Sun Mar 27 08:23:00 GMT 2005

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/