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@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@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?