Non-parallel version of GC
Simon Marlow
marlowsd at gmail.com
Mon Aug 19 10:51:23 CEST 2013
On 13/08/13 14:15, Edward Z. Yang wrote:
>> But perhaps there's another way to achieve your goals - what are the
>> interesting features you want to add?
>
> Yeah. The key thing I need to change is how the GC decides where
> live objects are evacuated to, to support a more efficient implementation
> of resource limits (think BiBoP for cost centers) where every user
> gets his own set of pages, and his objects are always evacuated to
> pages he owns. I don't know how to parallelize his, and even in
> the non-parallel case it requires quite a restructuring of the GC code.
You can think of this as abstracting two operations:
- deciding where to move the object
- deciding whether that creates a cross-generation pointer
(and if so, adding the parent object to the remembered set)
I imagine this is independent of generational GC (each generation is
split into multiple users) so the second question is unchanged - it just
compares the generation numbers of the source object and the destination.
So then you just need to manage the new sets of areas. Parallelism
doesn't add much complexity, you just have a set of destination areas
per generation per thread.
Cheers,
Simon
More information about the ghc-devs
mailing list