Related articles |
---|
translate Java VM bytecode to native code using GCC backends ? pascal@sema-taa.fr (Pascal.Girard) (1996-02-09) |
Re: translate Java VM bytecode to native code using GCC backends ? bothner@cygnus.com (1996-02-13) |
Re: translate Java VM bytecode to native code using GCC backends ? mad@nak.math.keio.ac.jp (MAEDA Atusi) (1996-02-19) |
Re: translate Java VM bytecode to native code using GCC backends ? bothner@cygnus.com (Per Bothner) (1996-02-19) |
From: | "Pascal.Girard" <pascal@sema-taa.fr> |
Newsgroups: | comp.compilers |
Date: | 9 Feb 1996 14:23:41 -0500 |
Organization: | Compilers Central |
Keywords: | interpreter, GCC |
Compilation of Java Virtual Machine bytecodes toward native machine
code is interesting for better performance, is known to be possible
given the specifications of JVM, and is expected from some machine
vendors at about mid-96.
I have curiosity about the possibility of using parts of GNU GCC to
achieve that compilation, thanks to a translator from ".class" format
to the internal form of GCC (the RTL), and then reuse of the backends.
There are several advantages :
- GCC has backends to produce code for a huge range of architectures.
- The optimisations performed on the RTL form are pretty good.
- The feasibility of alternative front-ends is certain (C, C++,
Objective-C, Ada, ...)
- The required work for the translator JBC->RTL should be simpler than
a full compiler, and is architecture independant.
- GCC is free and available everywhere. But we have no such garanties
for the eventual BC compilers from Sun or other (they may cost a lot,
once the "Java de facto standard" is well established).
I see some problems also :
- Is there enough compatibility between the models of JVM and RTL? If
the mismatch is too important, there may be a bad impact on
performances (which is the primary motivation)
- except the interpreter, the run-time of Java VM (threads, GC, native
libs, loader, ...) must be included : could it be borrowed from the
available JVM implemantations ?
- the BC compiler should act within the Java "real" machine, after
security checks on the bytecode : this implies a mix of Java and GCC
implemantations.
Answers ? opinions ?
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.