Alternate GCs

Will Coleda will at
Mon Sep 12 19:40:58 UTC 2011

I had forgotten about the infinite GC - that's probably worth keeping
a compile time choice for.

On Mon, Sep 12, 2011 at 1:35 PM, Nick Wellnhofer <wellnhofer at> wrote:
> IIRC this has been discussed on IRC quite a while ago. I think the consensus
> was that runtime selection of GCs is not very important.
> There are also two parts to the issue. The first one is the wrapper
> functions in src/gc/api.c. They could be folded into the GC backends with
> very small duplication of code. Then the users of the GC API could
> immediately make the indirect function call into the GC backend saving a
> function call in many hot paths.
> The second part is compile-time selection of the GC backend which is a lot
> more flexible. For example, new GC backends could use different memory
> layouts for GCables or use their own macros for certain operations.
> The work on the configure side shouldn't be too hard. I wrote the configure
> code for the new src/platform system and it's basically just selecting a
> bunch of .o files depending on a configure option. I can offer to help
> working on a similar system for the GC code. But it would be interesting to
> know if there are any users of the old GC backends at all. I always found
> the "infinite" GC useful for debugging, personally.
> Nick
> On 12/09/11 18:06, Andrew Whitworth wrote:
>> That would alleviate pain but would certainly be more work right now.
>> My big concern is testing this to see if there is a performance
>> improvement to be had. None of the cores we have besides GMS is worth
>> going through the effort for, and we don't even have plans on the
>> table yet for an alternate.
>> In reality, a system like what we have for src/platforms/* would work
>> very well for GC. We could set some macros at configure time and make
>> certain files be included in the build and others excluded, then we
>> could do static symbol binding on all GC symbols. That's a little bit
>> more effort than I would like to spend on this right now, especially
>> since I don't know if the performance gains will be worth it.
>> --Andrew Whitworth
>> On Mon, Sep 12, 2011 at 11:56 AM, Jonathan "Duke" Leto
>> <jonathan at>  wrote:
>>> Howdy,
>>> A while ago we talked about allowing GC's to be chosen at compile time.
>>> Wouldn't that alleviate this pain whilst still allowing GC's to be
>>> pluggable?
>>> Duke
>>> On Mon, Sep 12, 2011 at 7:59 AM, Nicholas Clark<nick at>  wrote:
>>>> On Mon, Sep 12, 2011 at 10:42:17AM -0400, Andrew Whitworth wrote:
>>>>> Is anybody out there using or relying on the alternate GCs besides
>>>>> GMS? I think I want to rip the older ones out. Right now, because GCs
>>>>> are pluggable, we have to go through an indirect function call for
>>>>> every single GC API call, and the C optimizer can't really do anything
>>>>> with that. I want to rip out the alternate GC cores and flatten some
>>>>> of the call graphs, to give the C compiler some opportunities to
>>>>> optimize the hot paths. I will put together a branch soon, but I want
>>>>> to double-check nobody relies on the old GC cores for any purpose.
>>>>> The idea of pluggable GCs is great in theory, but right now we only
>>>> The idea of pluggable GCs is great in theory, but I can't see how it can
>>>> be done (in practice, in a statically compiled language such as C)
>>>> without
>>>> needing a function call at every single *possible* GC API call. That is,
>>>> a call is needed at any point where the union of the implementations of
>>>> supported GCs need it, even if it's a no-op for the currently chosen GC.
>>>> (Such as a call needed for actions for a write barrier, which always has
>>>> to be made, because a runtime pluggable system can't inline the test for
>>>> whether an invariant has become breached, or remove it entirely for a GC
>>>> that doesn't need write barriers.)
>>>> I think compile time flexibility should possible without runtime pain.
>>>> But no flexibility is cheaper to maintain.
>>>> Nicholas Clark
>>>> _______________________________________________
>>> --
>>> Jonathan "Duke" Leto<jonathan at>
>>> Leto Labs LLC
>>> 209.691.DUKE //
>>> NOTE: Personal email is only checked twice a day at 10am/2pm PST,
>>> please call/text for time-sensitive matters.
>> _______________________________________________
> _______________________________________________

Will "Coke" Coleda

More information about the parrot-dev mailing list