Alternate GCs

Andrew Whitworth wknight8111 at
Mon Sep 12 16:06:29 UTC 2011

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