Am Fri, 10 Jan 2014 00:03:03 -0800 schrieb Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
> The GC comes up repeatedly in discussions around here. I've been > thinking for a while about breaking it down into components, and now it > seems the time is ripe. > > The design at http://goo.gl/ZVCJeB seems to be a win. It works well, > comprehends all major allocation tropes, someone implemented a subset of > it in C++ and measured good results, and a coworker is considering > adopting the design for a C++ project as well. > > I've started with the next logical step - higher-level allocation that > is aware of the type of the object being allocated, and realized that > integrating a notion of tracing is appropriate at that level, and > actually quite easy. So I'm thinking of just doing it. > > A few highlights: > > * The design will foster the small, composable components with > required/optional primitives that worked for std.allocator. > > * I plan to review and probably discard all of the pointers-to-functions > nonsense in the current GC. > > * At this point I won't worry about discovering roots; I assume druntime > has the appropriate mechanisms in place. Instead I'll focus on > primitives such as "given this root, mark all that transitively follows > from it" (conservatively or not). > > * I plan to rely on static introspection for the mark function, i.e: > > void mark(T)(ref T obj); > > would mark obj and everything transitively referred to by it. The > function would probably take a second parameter that's the heap that obj > is sitting in. > > * I plan to segregate all objects that don't include references and > pointers (e.g. int, int[], Tuple!(int, double) etc) into a completely > different heap than the "interesting" objects. For the simpler objects > there's no need to save detailed type information so they can be stored > in a more compact, efficient manner. > > * There will be no possibility to change the type of certain objects > once allocated. An allocation for an immutable object cannot e.g. make > it later a mutable one. (This is an essential issue with the current > allocator, I think.) > > * At this point I'm unclear on how generations can be componentized, but > am cautiously optimistic. Will see once I get to it. > > One thing that would be great now would be to make an effort to review > and merge the current precise GC work. I'm sure it will be of great help > with breaking into components. > > > Destroy. > > Andrei Nothing to destroy yet. But it does feel good that someone is putting the pieces together to come up with the second generation of D garbage collection. With pieces I mean the discussions about making it optional or allowing user defined allocators, how immutable can be used to an advantage, precise scanning and generational GC. Basically there are enough use cases now that one can shape a new GC model around it. -- Marco
