On Mon, 08 Feb 2016 11:22:45 +0000, thedeemon wrote: > On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: >> What language semantics prevent precise & fast GC implementations? > > easy type casting prevent precise GC.
To expand on this point: A GC makes a tradeoff between allocating efficiently and deallocating efficiently. (And a compiler+runtime makes a tradeoff between generating larger binaries that take more time to deal with and being able to produce precise garbage collection.) You can write a GC that allocates each type in its own region of memory. Every block has a pointer map associated with it. But this means the minimum allocation for each type is one page -- typically 4KB. This is bad for applications that have very few instances of each type and many types of object allocated. A simpler thing you can do is write a GC that has two regions of memory, one with pointers that might point to GC memory and one without. This gets rid of the overhead problem but doesn't allow precise collection. Alternatively, a language might prevent all casting, even upcasting, for any type that might contain pointers. Specifically: class Foo {} class Bar : Foo {} Foo foo = new Bar(); // type error! This means that the GC doesn't ever need to store the type of an allocated object anywhere. It can get the information it needs from a stack map ("pointer to Foo is stored in this stack frame at offset 8") and a similarly formatted map for allocated types. It would work, but it's sufficiently constraining that I don't think anyone has this in a real programming language.