Re: Plans for 2.8 - GNOME Managed Language Services?

[Miguel de Icaza <miguel ximian com>]

Hello,
 
> > As far as I am concerned (maybe I am biased), Java and the JVM offer no
> > advantages over mono.  But mono has several including: language interop
> > (managed to unmanaged and also the reverse),
> 
> Achievable in Java, see UNO, Jython, and so forth.

You can also write code written in any language on top of sendmail
macros, as it is turing complete.   But being turing complete does not
mean that it is optimal for hosting a multitude of languages.

In particular the ECMA CLI is well suited for handling unsafe languages
lik C, C++ and Fortran as well as functional languages like lisp,
haskell, ml and the rest of that group.  

This was achieved by bringing 14 languages during the development stages
from both commercial and academic groups to be ported to the MS VM, and
the feedback of these groups went directly into the VM.

As an example, the generics specification for the ECMA CLI v2 machine
had to change its semantics to allow the Eiffel folks to use this
feature on Eiffel instead of being forced to ignore it. 

> >  complete and mature open
> > source implementation based on two published standards
> 
> The Mono implementation is a pretty new codebase. I don't think the JIT
> is super sophisticated, it isn't ported to all platforms, etc. Yes these
> things can be addressed, but they can also be addressed for a JVM.

Everything or nothing are super sophisticated.  It only matters where
the bar is set.  

Mono's current JIT engine has a number of optimizations:

                           peephole   Peephole postpass
                           branch     Branch optimizations
                           inline     Inline method calls
                           cfold      Constant folding
                           consprop   Constant propagation
                           copyprop   Copy propagation
                           deadce     Dead code elimination
                           linears    Linear scan global reg allocation
                           cmov       Conditional moves
                           shared     Emit per-domain code
                           sched      Instruction scheduling
                           intrins    Intrinsic method implementations
                           tailc      Tail recursion and tail calls
                           loop       Loop related optimizations
                           fcmov      Fast x86 FP compares
                           leaf       Leaf procedures optimizations
                           aot        Usage of Ahead Of Time compiled code
                           precomp    Precompile all methods before executing Main

Granted, not as complete as GCC, but with a nice built-in SSA
representation for example, we just implemented Arrays Bounds Check
Removal as part of the Mono "interview" process. 

The ECMA CLI shines compared to Java because of two reasons:

	* Value Types (structs or "byte blobs")

	  Java has nothing like this, and a lot of the memory pressure 
	  that applications impose on the VM is caused by this.

	* Platform Invoke

	  Platform Invoke is a lot faster than JNI.  In the tests that
	  Novell did when choosing a platform for iFolder, P/Invoke was
	  faster (100 to 500 times faster, depending on the test).

	* Generics are first-class citizens on the VM.

	  In Java, Generics are compiler sugar, in the ECMA CLI, they
	  are first class components of the VM, and hence classes will
	  be inlined for specific data types, without any "boxing".

On the performance side of things, in my opinion C# got something right
that Java did not: the default for methods is to not be virtual, while
the default in Java is to be virtual.

Miguel