[Mono-list] gcc front-end and portability
Wed, 11 Jul 2001 08:27:34 +0200
Ok, you've convinced me that for an installation time JIT, a GCC backend
might not be a bad idea. I'm not 100% sure, but I don't think its a
waste of time to investigate it anymore.
On 10-Jul-2001, John Zedlewski <zedlwski@Princeton.EDU> wrote:
> >If you are saying forget JITting the code and just generate native code
> >from CIL, then it will probably work, but you lose runtime
> >verifiability, code mobility and all the other nice things that an
> >architecture neutral bytecode gives you.
> Hmm... I don't see why you lose that by generating native code from
> CIL, if you do it on the client machine. You can verify and compile
> everything at install-time, no? That way we only incur the overhead of
> compiling once. I definitely agree, though, that the gcc backend will
> be too slow for Java-style JIT-ing, but I really don't see an advantage
> to the JIT model at all.
> Most of the new research JVMs have moved over to a 2-JIT model, where
> you have one super-fast, but non-optimizing compiler and another slower,
> optimizing one for frequently-used methods. IBM's Jalapeno
> (http://www.research.ibm.com/jalapeno/publication.html) does this, as
> does Intel's ORP (http://www.intel.com/research/mrl/orp/). It might be
> possible to use gcc for optimization, but a non-optimizing, custom
> compiler for fast compilation on a handful of popular platforms.
> I just want to emphasize that it's really, really, really, really hard
> to build a good, cross-platform optimizing JIT from scratch. In the 5-6
> years that Java has been around, no open source or academic project has
> managed to do it (Sable, OpenJIT, and LaTTe are all machine-specific and
> they typically lose to the Sun, MS, and IBM JVMs by a factor of 2 in
> benchmarks). I really don't se a reason to believe that Mono-CLI will do
> better unless it starts from a strong foundation. But, hey, maybe I'm
> just too much of a cynic.
> Mono-list maillist - Monoemail@example.com