current gcjx status

Mon Mar 28 22:11:00 GMT 2005

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