Alternate GCs

Nick Wellnhofer wellnhofer at
Mon Sep 12 17:35:49 UTC 2011

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.


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.
> _______________________________________________

More information about the parrot-dev mailing list