Re: The MicroVM project

[Leonardo <leob@...>]

PS: forget to mentioned that I'm rather biased re OMR because of how
much I've worked with it.

Leonardo

On 2017-05-25 06:39 PM, Leonardo wrote:
> Since Lua Vermelha got mentioned :) , I'll make a note that it's built
> using Eclipse OMR (https://github.com/eclipse/omr), which has some
> similarities with MicroVM that are worth comparing (for those interested
> in language implementations).
> 
> The goal of Eclipse OMR is to provide reusable components for building
> language runtimes. This includes components providing platform and
> hardware abstractions and concurrency. It also includes components for
> building GCs and JIT compilers. In this sense, MicroVM and OMR provide
> similar value.
> 
> However, a big difference is that OMR is an implementation; not a
> specification. In this sense, OMR is closer to LLVM than MicroVM (though
> still very different than LLVM). The technology in OMR is also quite
> scalable. It's been used to build things as small as Lua Vermelha (still
> larger than PUC Lua though) and as large as IBM's JVM (which is being
> opensourced sometime this year, in case anyone is interested).
> 
> Lua Vermelha is still in it's very early stages. There's plenty of room
> for improvements and optimization. I've really enjoyed working on it so
> far though and I will try to spend more time working on it.
> 
> --
> Leonardo
> 
> On 2017-05-24 03:40 PM, Fabio Mascarenhas wrote:
>> On Wed, May 24, 2017 at 1:33 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
>>>
>>> I think a more interesting target would be the CLR, especially since Microsoft is going Open Source and acquired >Xamarin. I know Fabio Mascarenhas and Roberto worked on something like this in 2008 (there is a paper about it >behind the ACM paywall: http://dl.acm.org/citation.cfm?doid=1363686.1363743) but I have no idea if those efforts >have been pursued by anyone.
>>
>> There is NeoLua (https://github.com/neolithos/neolua). It should be at
>> least as fast as the Lua interpreter, and might be faster for some
>> workloads once the DLR caches have warmed up, even if you do not use
>> its optional typing (it can use optional type annotations like Ravi).
>>
>> With Truffle the JVM should be a better platform for dynamic
>> languages. There is a partial Lua implementation
>> (https://github.com/lucasallan/LuaTruffle) that is complete enough to
>> run the mandelbrot benchmark as fast as LuaJIT, once it has warmed up.
>> :-)
>>
>> LuaVermelha (https://github.com/Leonardo2718/lua-vermelha) is chugging
>> along, and the best bet if you want an implementation of Lua 5.3 right
>> now that is faster than the Lua interpreter.
>>
>> Roberto has a student working on using LLVM as a backend for a tracing
>> JIT, maybe he will chime in.
>>
>>> --
>>> Pierre Chapuis
>>>
>>
>> --
>> Fabio Mascarenhas
>>
> 
>