Re: Some JIT compilation challenges

[Hisham <h@...>]

On 8 February 2016 at 20:02, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> LLVM has the concept of a Module which equates to a 'translation unit'
> - within which there can be many functions.
>
> In Ravi at present each function is put into its own module - this has
> the advantage that a function is independent of every other function
> and when it becomes garbage, the collector releases resources.
>
> The model in Ravi doesn't scale very well - at least in terms of
> memory usage. I assume that each module in LLVM carries some overhead.
> It would be nice if multiple functions could be put into a module. Two
> approaches come to mind:
>
> a) User supplies a table of functions - they all get put into the same module.
> b) User compiles a source file - all functions in the source get added
> to the same module.
>
> The problem is that how and when should the module be collected? What
> happens if a function becomes garbage and later on user re-invokes it?

This is guesswork, but I think that in idiomatic Lua function lifetime
falls into two main categories:

* long-lived functions that are part of a Lua module - their lifetime
is associated to the lifetime of the enclosing module table, which is
usually the lifetime of the program
* short-lived closures that are created "inline" by other functions -
code that does stuff such as `return function() ... end`, where the
resulting function is used and then thrown away

For the former, I think you shouldn't worry about GC a lot. I'd make a
Lua module one big LLVM translation unit, add all declared functions
there and attach the lifetime of the LLVM unit to the Lua module
table.

For the latter, I think in most cases these short-lived functions
won't be worth JITting anyway.

But again, this is all guesswork.

-- Hisham