Non-parallel version of GC

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Non-parallel version of GC

Edward Z. Yang
Hello all,

How would people feel about an alternate GC implementation in GHC which
is not parallel?  A GC like this would be simpler to understand, maybe a
little faster when parallel collection is not being used, and (most
importantly for my case) easier to extend with interesting features.

In particular, this implementation would not have gen_workspace or
gc_thread; these would either be unnecessary or folded directly into the
actual generation object.

Thanks,
Edward



Reply | Threaded
Open this post in threaded view
|

Non-parallel version of GC

Simon Marlow-7
On 10/08/13 00:58, Edward Z. Yang wrote:

> How would people feel about an alternate GC implementation in GHC which
> is not parallel?  A GC like this would be simpler to understand, maybe a
> little faster when parallel collection is not being used, and (most
> importantly for my case) easier to extend with interesting features.
>
> In particular, this implementation would not have gen_workspace or
> gc_thread; these would either be unnecessary or folded directly into the
> actual generation object.

 From my point of view I'd like such a thing to be as separate as
possible from the rest of the GC code.  However it might be hard to do
that - you mentioned modifying the generation structure, for example.

As with most things in the RTS, the GC is "exactly as modular as it
needs to be right now", which in practice means "not quite modular
enough for what I want to do next" :-)  So your first step might be to
abstract some things so that the two GCs can coexist peacefully.

But perhaps there's another way to achieve your goals - what are the
interesting features you want to add?

Cheers,
        Simon





Reply | Threaded
Open this post in threaded view
|

Non-parallel version of GC

Edward Z. Yang
> 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.

Edward



Reply | Threaded
Open this post in threaded view
|

Non-parallel version of GC

Simon Marlow-7
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