Alternate GCs

Andrew Whitworth wknight8111 at gmail.com
Mon Sep 12 20:04:08 UTC 2011


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
>


More information about the parrot-dev mailing list