Perhaps this is naive, but it seems to me that a general-purpose allocator, as Ryan defines it, is a solution to a problem that doesn't have to exist in princip

Perhaps this is naive, but it seems to me that a general-purpose allocator, as Ryan defines it, is a solution to a problem that doesn't have to exist in principle. The allocator just needs to be able to move memory blocks around, so it can compact allocated memory. Probably the most natural way to enable this in C-ish languages is to use relocatable handles, as implemented by the original Macintosh memory manager and the Windows GlobalAlloc function (when using the GHND flag). In this scheme, the allocator doesn't return a pointer, but a handle, which has to be locked to retrieve a pointer whenever that piece of memory is being used. As long as most handles are unlocked most of the time, the memory manager is free to move blocks of memory around when necessary. In Ryan's parking-lot analogy, it's as if all parked cars could be moved around the lot at any time to avoid fragmentation. So I wonder if the inventor of libc's malloc was aware of relocatable handles and simply chose not to use them. Are there good reasons why we don't use relocatable handles in C/C++ today? Or is it just the weight of arbitrary history?