Seems reasonable to me to remove the runtime pluggability if there's a lack of alternatives.
Adding a compile-time option seems reasonable, but only if we have another serious contender. (And they can get themselves tested out in a branch by replacing the existing GC well in advance of needing the configure code in place.) On Mon, Sep 12, 2011 at 12:06 PM, Andrew Whitworth <[email protected]> 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 > <[email protected]> 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 <[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 >>> >> >> >> >> -- >> Jonathan "Duke" Leto <[email protected]> >> Leto Labs LLC >> 209.691.DUKE // http://labs.leto.net >> NOTE: Personal email is only checked twice a day at 10am/2pm PST, >> please call/text for time-sensitive matters. >> > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
