dafrito at gmail.com
Tue Sep 13 21:27:53 UTC 2011
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
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
More information about the parrot-dev