Re: current gcjx status

[Tom Tromey <tromey at redhat dot com>]

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

Per> One performance bug, I think, in the current front-end is that
Per> it reads too many classes.

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

Per> I don't know how well gcjx does in this respect - but jc1 seems
Per> to be doing a very bad job.

There should be no real difference here between jc1 and gcjx, I think.
It is probably a generic gcjx bug.

There's a flag in the compiler object controlling opportunistic
compilation.  This is set depending on what back ends are in use by
the current compilation; it is only set if we are generating bytecode
and nothing else.  (Probably this should be more explicit so that "gcj
-C" can disable it, if that's what we want.)

Tom