Alternate GCs

Tue Sep 13 02:09:56 UTC 2011

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 <christoph at mksig.org> 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"
> <wknight8111 at gmail.com> 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 <will at coleda.com> 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 <wellnhofer at aevum.de> 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
>> >>> <jonathan at leto.net>  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<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
>> >>>>> _______________________________________________
>> >>>>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Jonathan "Duke" Leto<jonathan at leto.net>
>> >>>> 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
>