[Mono-devel-list] VM differences with java

[Jonathan Pryor]

Yet another take on the answers...

On Tue, 2005-01-11 at 11:51 -0800, Peter Gerdes wrote:
> 1)  Is there any reason not to have the JIT compiler cache the native
> code snippets/SSA tree after being run and then reload them if
> appropriate?

Yes.  Malloc(3) is used to allocate the memory in which the JITed code
is placed, and malloc(3) will return different memory addresses on
different runs of the program.  Since the JIT inserts direct memory
addresses into the generated code (it's faster), this memory can't be
reused the next time the process is launched.

If you want to save the generated code, use the Ahead Of Time JIT
support, via mono's --aot argument.  This generates less-optimal code
(e.g. no direct memory addresses) but permits reusing the generated
code.

(Someone will flame me for calling AOT code "less-optimal", and they'll
be both right and wrong.  AOT vs. JITed code include a number of trade
offs, and it's nigh impossible to say which is "better" without
measuring for your particular scenario, and what your definition of
"better" is.  For example, JITing code *can* be faster than loading AOT
code if the disk cache is cold, since you'll be hitting less disk.)

> 3) Did any of the dynamic/profiling  optimizations ever make it into
> the code generation?

Not yet.  This is something we'd like to have, but no one is working on
it AFAIK.  I believe lupus plans on working on it within the next few
months, but I could be mistaken.

> Finally, out of curiosity since the CIL instruction set seems so
> similar to the JVM bytecodes what was the motivation to write your own
> full JIT system rather than expanding an existing JVM or even
> translating CIL instructions to java bytecodes?

CIL and JVM bytecodes are about as similar as PPC and x86 opcodes.
Sure, they both have ways to load arguments and do computation, but
there's more to supporting an intermediate language than that.

See also:

http://lists.ximian.com/archives/public/mono-list/2002-September/008623.html
http://lists.ximian.com/archives/public/mono-list/2002-September/008586.html

Massimiliano Mantione also listed a number of things unique to the CLI
that a JVM doesn't need to support, including value types, delegates,
unsafe pointers, and reference arguments (C# "ref" and "out").

In short, capability-wise, CIL is a superset of JVM bytecodes.  CIL ->
bytecode is possible, but not easy (and may not be fully possible if the
CIL contains too many unverifiable constructs).  Bytecode -> CIL is
easier, since CIL can easily express everything Bytecode can; see IKVM.

Also, I'm not aware of any good open-source/free software JVMs that
existed when Mono was started in May 2001.  Personally, I hadn't heard
of SableVM until last year, and GCC doesn't qualify as a JVM (it
compiles JVM bytecode into native code), so I don't think that there was
a JVM that Mono could build upon even if Mono had wanted to.

 - Jon