[LLVMdev] Stack roots and function parameters

[Nathan Jeffords]

snip


>
>> > My problem is that I can't see how to address this without generating
>> > horribly bloated and inefficient code. Pretty much every function
>> argument
>> > that isn't a simple integer or float will have to be copied to a hidden
>> > local variable before every function call - in addition to copying it to
>> the
>> > stack to create the call frame. Even local variables are not immune if
>> you
>> > allow closures in your language. Under this scenario, calling
>> conventions
>> > that pass arguments in registers are utterly futile and save nothing,
>> > because everything has to get copied to the stack anyway.
>>
>> One way or another, stack roots *must* get copied to the stack, so
>> that the GC can find them.  Remember the GC is usually running in some
>> other thread and can *only* find pointers that live somewhere in
>> memory (either the stack or the heap).
>>
>
I think the logic is that by putting the responsibility for having stack
roots on the caller, the callee's do not need to
concern themselves with their arguments. A function using a gc'ed pointer
assumes that a caller somewhere up the call-chain has created a gcroot for
that pointer that will outlive its invocation therefore it doesn't need to
do anything with the garbage collector.

In the case of the 'this' pointer, only the function that got the 'this'
pointer from somewhere else (global, heap) would be responsible for creating
a gcroot, once this is done the 'this' pointer can be passed through any
number of calls and no more roots are required as long as the pointer is not
stored somewhere that will outlive the invocation.

snip

-- Talin
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
- Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100922/fbd326fd/attachment.html>