[LLVMdev] Improving Garbage Collection

Kenneth Uildriks kennethuil at gmail.com
Thu Jul 7 15:38:18 PDT 2011

Y'all are right... I was in the car and realized I needed to account
for all of that and didn't get a chance to issue a retraction.

On Thu, Jul 7, 2011 at 5:31 PM, Frits van Bommel <fvbommel at gmail.com> wrote:
> On 8 July 2011 00:07, Kenneth Uildriks <kennethuil at gmail.com> wrote:
>> You don't need function parameters to be stack roots.  You already
>> have a stack root for those values in the calling function, right?
> Allowing parameters themselves to be stack roots allows an object that
> the calling function itself no longer needs to be collected once the
> called function (and everyone else, obviously) is done with it.
> It would also make tail calls easier to support: if parameters can't
> be stack roots, the called function would have to copy each pointer
> parameter to a stack root before doing anything else, or at least make
> sure the GC doesn't kick in before it does so. And it would have to do
> so whether or not it's ever actually tail called, because it (usually)
> can't know who calls it and how.
>> Anyway, declaring the function parameters as stack roots means that
>> you *must* pass pointers into the GC heap to those functions, whether
>> or not it makes any difference to the function itself.  That means,
>> among other things, that optimization passes for turning GC
>> allocations into pool allocations or local allocations become more
>> complicated.
> Not if the GC is smart enough to ignore pointers that don't point into
> its heap. This shouldn't be that much extra work to achieve because it
> needs to figure out what object a pointer points to anyway (at least
> if interior pointers are allowed). If a pointer doesn't point to an
> object it knows about, it can simply be ignored.
> This does depend on the structure of the GC heap though: if the GC
> knows beforehand which pointers point into its own heap the "figure
> out what object it points to" algorithm may be able to use some tricks
> that aren't safe otherwise.

More information about the llvm-dev mailing list