Re: Some JIT compilation challenges

[Patrick Donnelly <batrick@...>]

On Wed, Feb 10, 2016 at 4:06 PM, Coda Highland <chighland@gmail.com> wrote:
> On Wed, Feb 10, 2016 at 12:42 PM, Dibyendu Majumdar
> <mobile@majumdar.org.uk> wrote:
>> On 10 February 2016 at 12:32, Hisham <h@hisham.hm> wrote:
>>> 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.
>>>
>>> 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.
>>>
>>
>> Thanks Hisham, this sounds like a sensible approach.
>>
>> Regards
>> Dibyendu
>>
>
> The problem with this approach:
>
> mt = {
>   __index = function(t, k) end,
>   __newindex = function(t, k, v) end
> }
>
> Are these functions "declared" in the module, or are they defined inline?
>
> function closure_based_object()
>   var private_member = 123
>   return { get_value = function() return private_member end }
> end
>
> What about this one?

>From a bytecode perspective, you would probably only add functions to
the module which are generated by a CLOSURE instruction in the chunk's
main function. [Keep in mind that there is a 1-1 mapping between
function prototypes and CLOSURE instructions.]

-- 
Patrick Donnelly