4 ms·

An interesting approach: giving each thread its own "young generation" sub-heap, so transient objects can be disposed of without coordination from other threads

An interesting approach: giving each thread its own "young generation" sub-heap, so transient objects can be disposed of without coordination from other threads / CPUs and their cache pages.

larsberg 16y ago
We've been doing this in Manticore since 2008 or so. We couldn't really get speedups past 12 cores without it (we have a "typical" parallel GC implemented as well to test against). Hopefully we'll get the paper on the GC and associated language trickery - we don't allow pointers between young generations - in somewhere soon :)
- simonmar 16y ago
  Yes, the GHC design has certainly been influenced by Manticore (that was one of the "other designs" I referred to). Though in GHC we do have some different problems to solve, the worst of which is that we have to support a bunch of programming abstractions that use mutation.
scott_s 16y ago
I worked on a memory allocator (as in malloc, not garbage collection) that takes a similar approach: http://people.cs.vt.edu/~scschnei/streamflow/ http://people.cs.vt.edu/~scschnei/streamflow/ A group at Intel independently came up with a similar approach as well: http://portal.acm.org/citation.cfm?id=1133967 http://portal.acm.org/citation.cfm?id=1133967
- Roboprog 16y ago
  Cool, the steamflow thing sounds interesting. Is there a top level example or test-driver somewhere in the github project showing what typical use-cases are? E.g. - I have a test-driver here: http://github.com/roboprog/buzzard/blob/master/test/src/main.c http://github.com/roboprog/buzzard/blob/master/test/src/main... (although I have barely started the library I was tinkering on) Any example client program for your allocator? I'd like to see what use cases you are handling.
  - scott_s 16y ago
    The Larson and Recycle benchmarks are on github. You can read about them in the paper. Email me if you'd like to see an unpublished paper which has some more detail on the allocator's design.

An interesting approach: giving each thread its own "young generation" sub-heap, so transient objects can be disposed of without coordination from other threads / CPUs and their cache pages.

larsberg 16y ago

We've been doing this in Manticore since 2008 or so. We couldn't really get speedups past 12 cores without it (we have a "typical" parallel GC implemented as well to test against). Hopefully we'll get the paper on the GC and associated language trickery - we don't allow pointers between young generations - in somewhere soon :)

simonmar 16y ago
Yes, the GHC design has certainly been influenced by Manticore (that was one of the "other designs" I referred to). Though in GHC we do have some different problems to solve, the worst of which is that we have to support a bunch of programming abstractions that use mutation.

scott_s 16y ago

I worked on a memory allocator (as in malloc, not garbage collection) that takes a similar approach: http://people.cs.vt.edu/~scschnei/streamflow/ http://people.cs.vt.edu/~scschnei/streamflow/ A group at Intel independently came up with a similar approach as well: http://portal.acm.org/citation.cfm?id=1133967 http://portal.acm.org/citation.cfm?id=1133967

Roboprog 16y ago
Cool, the steamflow thing sounds interesting. Is there a top level example or test-driver somewhere in the github project showing what typical use-cases are? E.g. - I have a test-driver here: http://github.com/roboprog/buzzard/blob/master/test/src/main.c http://github.com/roboprog/buzzard/blob/master/test/src/main... (although I have barely started the library I was tinkering on) Any example client program for your allocator? I'd like to see what use cases you are handling.
- scott_s 16y ago
  The Larson and Recycle benchmarks are on github. You can read about them in the paper. Email me if you'd like to see an unpublished paper which has some more detail on the allocator's design.