[Mono-devel-list] VM differences with java

[Massimiliano Mantione]

My two cents, others will give better answers...
If I say stupid things please somebody correct me, I'm also
testing if I got things right ;-)

On Tue, 2005-01-11 at 20:51, 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?

Do you mean for inlining?
Caching native code would not be appropriate, the point of inlining
is not only to avoid the call, but also to be able to optimize the
"called" (now inlined) code *inside* the calling code.
On the other hand, caching the IR would be technically feasible, but
not necessarily such a big advantage IMHO.
The cached IR would need to be "merged" with the IR of the caller,
including local variables and basic blocks... at the very least
memory management would be a mess (the current use of memory pools
is quite clean and simple).
And since inlined methods are small, recompiling them from CIL is
not that bad, and no memory overhead is wasted keeping MonoInst
trees around.

If, on the other hand, by "caching" you mean AOT, well, that works
already.

> 2) Does anyone have any advice on what are the best papers to read on
> the code generation system.  I have been plowing through several BURS
> related papers but figured some advice from people who know might be
> helpfull.

Sorry, I'm not an expert on this, I just read the Fraser book...

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

Not yet, but Paolo just committed the statistical profiler (without
an on line profiler you simply cannot do those things...).

> 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?  Since you now seem to
> be faster than any opensource JVM implementation it is all irrelevant
> now but I'm just curious if there was any particular reason which
> would have made this impractical.

About translating CIL to Java bytecode... I think we would have
had a very hard time at least with the following, in random order:
- unsafe pointers
- delegates
- marshalling
- p/invoke
- value types
- low level remoting things (the way remoting proxies work)
- also appdomain behaviour would have been hard to do IMHO
I'm not saying it is impossible, probably the guys at Mainsoft
solved exactly those issues...
I'm just saying it's hard, and (likely) suboptimal.
And then in order to have a free (libre) system you would need to
have a free JVM, which brings us to the next point...

About the decision to start from scratch instead of taking an
existing open source JVM and modify it... I wasn't here when it
all begun, but I remember the quality of open source JVMs was
really, really low, and at most you could reuse part of the jit
and code generator, the class loader, verifier and so on had to
be rewritten anyway to work with CIL, and so all the .NET class
libraries, high level (C#, VB, EcmaScript) compilers...

Hope this helps...

Ciao,
  Massi