Alternate GCs

[Aaron Faanes]

Aaron Faanes <dafrito at gmail.com>

On Sep 12, 2011, at 9:59 AM, Nicholas Clark <nick at ccl4.org> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev

It's certainly not worth the effort to implement at this point, but C++ templates would allow selection of different GCs at compile-time without incurring the runtime overhead of indirect function pointers (or the mental overhead of lots of macros).

Just a thought!

- Aaron Faanes