Alternate GCs

Will Coleda will at coleda.com
Mon Sep 12 16:11:57 UTC 2011


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
<wknight8111 at gmail.com> 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
>



-- 
Will "Coke" Coleda


More information about the parrot-dev mailing list