Aaron Faanes <[email protected]> On Sep 12, 2011, at 9:59 AM, Nicholas Clark <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
