I had forgotten about the infinite GC - that's probably worth keeping a compile time choice for.
On Mon, Sep 12, 2011 at 1:35 PM, Nick Wellnhofer <[email protected]> wrote: > > IIRC this has been discussed on IRC quite a while ago. I think the consensus > was that runtime selection of GCs is not very important. > > There are also two parts to the issue. The first one is the wrapper > functions in src/gc/api.c. They could be folded into the GC backends with > very small duplication of code. Then the users of the GC API could > immediately make the indirect function call into the GC backend saving a > function call in many hot paths. > > The second part is compile-time selection of the GC backend which is a lot > more flexible. For example, new GC backends could use different memory > layouts for GCables or use their own macros for certain operations. > > The work on the configure side shouldn't be too hard. I wrote the configure > code for the new src/platform system and it's basically just selecting a > bunch of .o files depending on a configure option. I can offer to help > working on a similar system for the GC code. But it would be interesting to > know if there are any users of the old GC backends at all. I always found > the "infinite" GC useful for debugging, personally. > > Nick > > > On 12/09/11 18:06, Andrew Whitworth 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 > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
