&gt; <i>the language should allow you to express simple memory ownership when you have it</i><p>The problem is that you only <i>think</i> you have such a thing. If you&#x27;re wrong, you&#x27;re screwed. :)<p>&gt; <i>The third and maybe most important optimization is to make garbage collection a per-thread operation. You simply don’t allow garbage collected heap allocations to transfer between threads. </i><p>This takes away much of the point of threads, leaving you better off with processes---and process boundaries will better enforce this model. You cannot cons up a message, pop it in a queue, and have another thread pick that object out the other end: thus you have to use some IPC based on bytes in a pipe or shared memory buffer.<p>In other words, you might as well fork a bunch of children that have not just their own heaps but their own address spaces to enforce the containment of those heaps. There is a lot of good in it: fault isolation, more virtual memory footprint to each little worker. There is a degree of attractiveness in multiple processes with just one thread in each one, and single-threaded garbage collection (which doesn&#x27;t have to deal with hairy concurrency problems, and so is faster and more robust).<p>&gt; <i>To figure out which region a pointer refers to in this scheme, we simply loop through the different region sizes that our allocator allows, mask the appropriate number of bits from the pointer to get the start of the proposed region, read the region index in the first DWORD of this memory area (this may be garbage if we have the wrong size) use this to index into the region pointer array (taking care to avoid buffer overruns from garbage indices) and ensure that the pointer stored in that element refers right back to the proposed region. We also must ensure that the size of the region at this address actually contains the original pointer. </i><p>The problem of mapping a pointer to a region is already solved very well with existing data structures. For instanc, the Linux kernel uses a red-black tree to map a virtual memory pointer to a &quot;struct vm_area&quot;.  (These are the regions allocated by mmap).  The regions don&#x27;t overlap and so a binary search tree ordered by their base address works fine.<p>Solving the problem of &quot;does this pointer refer to a heap, and which one&quot; in a garbage collector is only necessary when we are doing conservative garbage collection: we are given some pointer-sized value from somewhere (like a scan of some raw memory area such as a C stack), and we have no idea whether or not the value is a pointer to an object in the GC world. An always-precisely-tracing garbage collector never has to solve this problem. It starts with root values, which are known to be objects in the GC world. If they are heap values, they point to objects whose structure is known to the collector. They are precisely traversed to reach other objects and so on.