[gambit-list] Configure options

Álvaro Castro-Castilla alvaro.castro.castilla at gmail.com
Thu Mar 10 17:21:22 EST 2016


Nice, thank you Marc!

Just to draw some (preliminary) conclusions: it is also STW, and in
this case you have to take care that the heaps fill their heap at
similar rates, because if one fills the other threads will stop their
work too. Although I guess the "work stealing" part compensates for
that. Is this correct?

Are you pushing progress to Github?



On Thu, Mar 10, 2016 at 8:13 PM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> The parallel GC is a Cheney-style copying collector of the “work stealing” variety.  Each “processor” (in reality, an OS thread) has its own set of roots (the Scheme thread it is running, its stack and registers).  When the heap memory has been filled, all processors interrupt their current work to start a synchronous collection.  Each processor marks its roots, and then proceeds with scanning the objects it has copied to tospace.  This is done with little synchronisation with other processors.  When a processor finishes scanning the objects it has copied, it steals scanning work from other processors.  The GC ends when all scanning has been done.
>
> Obviously I’m skipping all the nitty gritty details.
>
> Marc
>
>
>> On Mar 10, 2016, at 12:33 PM, Álvaro Castro-Castilla <alvaro.castro.castilla at gmail.com> wrote:
>>
>>> Multi-processor support is actively being worked on and in particular, a parallel GC is being implemented.  It is not currently operational, so there is no need to use those configure options at this moment.
>>>
>>
>> That's exciting! \o/
>> What approach are you following for the GC, Marc?
>



More information about the Gambit-list mailing list