[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Some JIT compilation challenges
- From: Hisham <h@...>
- Date: Wed, 10 Feb 2016 10:32:03 -0200
On 8 February 2016 at 20:02, Dibyendu Majumdar <firstname.lastname@example.org> 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
For the latter, I think in most cases these short-lived functions
won't be worth JITting anyway.
But again, this is all guesswork.