== Quote from Sean Kelly (s...@invisibleduck.org)'s article > == Quote from Christopher Wright (dhase...@gmail.com)'s article > > > > This isn't unreasonable, and it really just depends on how complete and > > how fast D's runtime reflection is. > This would incur more memory overhead as well. Right now, we make > do with one bit per block that indicates whether the block should be > scanned for pointers, while this may theoretically require a pointer > to TypeInfo per block in order to perform precise scanning. > Sean
Under what use cases would this extra few bytes really matter? What kinds of programs allocate so many objects that this overhead would be significant in practice? Note that I'm not advocating a moving GC, because in a systems language like D, where working with pointers and untyped memory blocks is supposed to be feasible, I think it would create more problems/limitations than it solves. For example, now it's ok to store a pointer to GC allocated memory in an area not scanned by the GC, such as the C heap or a memory block marked as NO_SCAN, as long as you also have another pointer to it somewhere else. With a moving GC, this would become problematic. However, a more precise non-moving GC (scans the whole heap precisely, only imprecise on the stack) would be nice if it can be reasonably implemented.