This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: current gcjx status
- From: Per Bothner <per at bothner dot com>
- To: tromey at redhat dot com
- Cc: GCJ Hackers <java at gcc dot gnu dot org>
- Date: Sun, 27 Mar 2005 00:23:39 -0800
- Subject: Re: current gcjx status
- References: <m3u0mxloyi.fsf@localhost.localdomain>
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/