Wasn't there talk recently of adding GC integration to profiling? Would that be a use-case for a separate, runtime pluggable GC core? Or would we rather put a lot of branching in the ordinary GC core to support rarely used functionality? Hookable gc and pluggable GC seem very similar to me.
On Mon, Sep 12, 2011 at 5:52 PM, Christoph Otto <[email protected]> wrote: > This is the approach I was going to suggest. If we want to say that our > GC will not need to be improved in the foreseeable future, limiting > ourselves to a single GC algorithm is fine. However, I would strongly > advocate compile-time GC selection. Since we're now free to make > reasonable* breaking changes, we should make it minimally painful to > allow continued GC experimentation. Although gms can be tuned to > imitate inf, I'd like to keep inf around so we have more than one user > of the interface. > > I'll defer to others on the value of ms2 and ms. I suspect they're not > long for this world. > > Christoph > > * allhlltest, talk to Rakudo, keep HLLs happy, etc > > On Monday, September 12, 2011 4:04 PM, "Andrew Whitworth" > <[email protected]> wrote: >> Okay, here's what I'm going to do. I'm going to rip out the ms2 GC >> core, rip out the command-line --gc option, and flatten the GC API >> calls down in a branch. That way we can see if there really is any >> kind of performance gains to be had and if so, how much. If we like >> what we see, we'll set up the necessary configure-time architecture to >> make the inf GC a selectable option at configure time. >> >> --Andrew Whitworth >> >> >> >> On Mon, Sep 12, 2011 at 3:40 PM, Will Coleda <[email protected]> wrote: >> > 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 >> > >> _______________________________________________ >> http://lists.parrot.org/mailman/listinfo/parrot-dev >> > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
