Re: Question on compiling to bytecode

[Jim White <jim at pagesmiths dot com>]

Erol Akarsu wrote:
> What about Kawa  should have also an option to generate
>  full Java source code translation instead of bytecode. Therefore,
> Gcj will have opportunity to apply full optimization power on it. Can
> we make it?

I don't know what specific optimizations that GCJ could make on Java 
source that it wouldn't make on Java bytecode, but I'm skeptical that it 
would have a material effect in most applications.  If a particular 
sequence is identified, it would be a straight forward matter to adjust 
Kawa's compiler, GCJ's optimizer, or to use a bytecode tuning stage.

As far as Java bytecode performance goes, beware of assuming that 
because it is doing static compilation that GCJ is delivering superior 
performance.  My understanding is that Sun's Hot Spot JVM (which is 
available without charge in the JDK and JRE) is typically faster (apart 
from bytecode loading/compilation time) than GCJ.

Also there are commercial static bytecode compilers that will do a 
better job than the present GCJ implementation, such as TowerJ.

http://www.javaperformancetuning.com/resources.shtml

If you're looking for top speed, there are numerous Scheme and Common 
Lisp implementations that go through GCC (and some, such as BigLoo 
support both the JVM and C).

Finally, be sure that you've actually got a working system (or at least 
the part that is performance critical) before expending resources on 
tuning performance of the language engine or libraries.  There are 
almost always large tuning options with better return-on-investment that 
a little profiling will illuminate directly.

Jim