[gambit-list] Configure options

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


On Thu, Mar 10, 2016 at 11:40 PM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> Not really… The thing is that there is one conceptual heap per VM, but the heap is composed of a bunch of sections (called msections for “movable sections”, i.e. sections containing movable objects).  Each processor starts off with one msection for its heap allocations and one msection for its stack allocations, and the unused msections remaining are kept in a free list.  When a processor overflows its heap, it gets the next msection from the free list and continues allocating in that msection.  So it is only when the free list of msections is exhausted that the synchronous GC is started.  One processor may have consumed 2 msections and the other 100, it doesn’t have to be balanced to achieve good usage of memory.  The msections are small enough that the unused part within the last msection used by a processor (before a GC) will not impact performance much.  Anyway, that is the theory that will have to be verified through experiments.


Ah, I understand, makes sense. Thanks for the explanation.
Out of curiosity, what lead you to choose this style of parallel GC?




>
> Marc
>
>
>> On Mar 10, 2016, at 5:21 PM, Álvaro Castro-Castilla <alvaro.castro.castilla at gmail.com> wrote:
>>
>> 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