[Mono-list] Future of JIT

[Jonathan Pryor]

The biggest problem is the licensing issues -- it's not GPL compatible. 
At least, not immediately so.

The problem is the "you may not sell vcode or any product drived from it
in which it is a significant part of the value of the project."  If mono
were to use this as its JIT, it could be argued to be a "significant
part of the value of the project" (the JIT is very important), which
means you can't sell it, which directly conflicts with the GPL.

The requirement to "acknowledge the use of vcode clearly in all product
documentation and distribution media" also conflicts with the GPL.  This
is similar to the original BSD's "obnoxious advertising clause"; see:

	http://www.gnu.org/philosophy/bsd.html

Note, I am not a lawyer, don't trust me, yada-yada-yada, but this is my
current understanding of the licensing issues.

The other problem is that a new JIT engine is already under
development.  It is described (briefly) in this presentation:

	http://primates.ximian.com/~miguel/slides-europe-nov-2002/ETH.sxi

I think it's also mentioned in some of the other presentations, but I
haven't checked.

In particular, start reading at Slide 26.  Benefits are greater
portability, better code generation, more flexible, and it's as fast or
faster than the current JIT.

 - Jon

On Sat, 2003-02-01 at 20:34, Ilya Minkov wrote:
> Have you considered VCODE/ICODE to become a basis for your JIT backend?
> 
> It was developed/used for runtime code generation in Tick C Compiler, 
> which is in turn based upon LCC. And since its command set is tuned for 
> LCC, it should also fit the .NET architecture if i'm not wrong. I 
> haven't read many important papers because of lack of time, so don't 
> consider what i tell here sole truth, it can have rumors/ 
> misconceptions/ stuff mixed in.
> 
> It has been well ported to all (widespread) RISC CPUs, and there is a 
> half-broken x86 port. I have been intending to make a "real" x86 port 
> for use in some project of mine. But i think MONO could be a better use 
> for me, and i would like to be of use if i have time and our targets match.
> 
> VCODE is a set of C macros, generating target machine code out of the 
> generalized RISC set without intermediate representation, like GNU 
> Lightning does. With a difference that GNU Lightning is broken.
> 
> ICODE is a form of binary representation for VCODE, which also 
> integrates a number of generic optimisations and register allocation, 
> reaching considerable execution speeds.
> 
> The thing to check: *licensing issues* (?), i don't know under which 
> condition it has been licensed.
> - checked already. It's "fair use" - not to sell, else use as desired, 
> retain copyright. It even allows usage in commercial products but it 
> doesn't matter.
> 
> I think the system should be as staged as possible, so that only a minor 
> part should be ported to another architecture, and that improving some 
> actually platform-independant stuff wouldn't break some platform while 
> leaving others working. Besides, this VCODE already contain a lot of 
> work done by others.
> 
> I also think that it should be possible to attach a peephole optimiser 
> to VCODE. Any time a label is issued, if optimiser is enabled, it would 
> disassemble (simplified, extracting a minimum of information) all the 
> code generated since the last label, and write "tags", noting where each 
> CPU command starts and some basic properties of it, like LCC-Win32 does 
> it. Then, peephole optimisation is basically pattern-matching and 
> disassembling certaing commands as this information is needed, and so on 
> as usual. Finally, the last label should be moved back.
> 
> Then i think, compilation should be "lazy". The first time a function is 
> compiled, it is done the fastest way, optimising nothing. Functions 
> which it requieres are not compiled. Inputs are placed on stack as 
> usual, but with a CALL to some (assembly-written) dispatcher function. 
> This dispatcher when called does the folowing:
>   - Looks at return adress. Using that, finds out what function exactly 
> is to be called in this place. (This information needs to be generated 
> when compiling that original function)
>   - If the function to be called is already compiled, then change the 
> call adress (which is just placed before the return adress) with the 
> actual function adress to be called, and call this function, then return.
>   - If the function is not yet compiled, compile it, then procede as in 
> previous case.
> The next time a function will call another function directly
> 
> First time a function is compiled it is compiled without optimisations. 
> I guess it would be OK to place a call to counter in the beginning of 
> such a function - since it's not compiled for speed...
> As soon as this counter decides that the function has been called "often 
> enough", it should recompile the function with all optimisations on, 
> this time without embedding the counter. The system to replace adresses 
> might either be the same as previous, or more a more rapid one so that 
> the unoptimised function can be deleted at once.
> 
> Of course, there can just as well be multiple optimisation steps, but it 
> might be the next step.
> 
> Opinions?
> 
> -i.
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list