[Mono-list] Intel and the CLR?

[int18@MIT.EDU]

> > I also do not see the point -- one compiles (ie. JIT
> > compilation) MSIL into x86 assembly (or any other processor assembly
> > language) anyways before running it anyways.  Thus the only benefit is
> > that one does not have to JIT code before running it.  But even this
> > benefit is minimal considering that .NET currently caches the result JIT
> > binaries between sessions.
> 
> Are you sure?  Last time I looked, .NET did *not* automatically cache the
> JIT binaries between different invocations of the same program.
> It would cache it between different invocations of a method, but it was
> an in-memory cache that would only last as long as the process.

Caching binaries on disk sounds like an incredibly bad idea due to
security issues.  Someone could replace the copy in the cache with a
program that does something that is completely different and you would
have no way of telling.  Also, compiling a IL program down to machine
code makes the program no longer verifiable.  Something that you could
potentially do is have a single copy of the program in memory if 1 or
more instances of the program are running.  This sounds hard though but
would be very useful if applied at least to libraries.  Another idea is
to have some extra information that tells the JIT engine some machine
specific information about sections of the code (where are the critical
loops, what randomness works best for the allocator) so that the JIT can
do a better/faster job next time.

The idea of implementing the CLR in hardware is a bad call.   The CLR
models a stack machine and not running the IL executables though a JIT
would make it hard to get good performance.  All the back end compiler
optimizations would never be applied to the code.  This is a problem
because good register allocation/use is necessary for good performance
in modern processors.  

-Antonio