[Mono-devel-list] VM differences with java

[Paolo Molaro]

On 01/11/05 Peter Gerdes wrote:
> I apoligize if this is a silly quesiton but I have been thinking of
> getting involved in the low level code generation algorithms for

Nice. We have some docs in mono/docs you might want to read.
Though I guess I should review them since they may have bitrotted.

> 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?

The native code can be saved using the aot compiler (there is also some
experimental code to do this automatically).
As for the intermediate representation: the IL metadata is alread a compact
representation that's good enough. Saving and restoring the ssa-based internal
representation would take too much effort to code and it would take more
time to process than the IL code, so I don't think it's worth it.

> 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.

I actually never found good papers on code generation (or at least
they don't have useful details to help build a working codegen).
Feel free to ask questions on this list if you need details of how the
mono code works.

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

SVN has the infrastructure to get the data and soon we'll be able to
replace already compiled methods with new methods implementation.
After that, someone will have to implement the code
to analize the data and trigger the recompilation.

> 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.

The JVM requires a much simpler JIT than mono needs to implement the 
ECMA specs, since the java bytecode is less complex than IL bytecode.
As such, any JVM jit would need significant changes to be able to execute
IL bytecode and the open source jits were coded with lots of assumptions
about the JVM, which is expected. At the time there were two types of OSS
java jits:
	*) kaffe: highly portable, but also low-performing
	*) some fast jits which worked only on some risc platforms
	*) lisp/functional related jits

The reason we didn't use the kaffe codebase is that we want mono to
be a system component on unix systems: as such it needs to be able to
generate fast code and with low overhead. This is also why we don't spend
resources on the interpreter: an interpreter, even if it's made fast,
has no place as a pervasive system component as we want mono to be.
Besides, at this time, the mono jit has been ported to 5-6 architectures
and it's reasonably portable, so there is no point in writing an interp
for portability. We expect 2 or 3 additional ports by the end of the year, too.
The reason we didn't use the risc-based jits is the same reason they were
developed in the first place: writing a jit for a risc system is much easier
than writing it for x86. But people use x86 systems and we wanted to
solve the hard poroblems first:-)
There are some very advanced jits for functional languages, but
they are usually not written in C, so they are of little use for us.

I think we are on a good path to achieve our goals: mono 1.0 is a good
enough system for desktop applications and experimetal servers. mono 1.2
is good for small and medium server apps and it also has changes to
more easily scale down for embedded use. mono 2.0 will cover a wide
range of application scenarios, from smp systems to GUI clients to
embedded applications.

If we were to start writing a jit now, we'd take a serious look at
llvm. While it is far from being able to execute IL code, it seems to be
a good starting point (well, once you decide you want to pay the C++ 
baggage tax:-). But as you point out, at this point this is moot: we are
not done yet, but we have a more portable JIT, we're adding optimizations.
Mono is becoming the reference JIT in the free software world, in fact it
would be good if someone were to write a book on jit internals based on 
mono for the academic world: it would help tremendously.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better