Oh, *dear*. Here we go with MacOS again!
If you have a 64-bit address space, is it *really* going to be
that expensive to keep the block info somewhere else? Do you
*really* need to munge-up the pointers? Especially given that
many 64-bit-address-space machines will really have 128-bit
(or wider) paths to memory, so with some care, you will still
be able to grab the full "fat pointer" in one cycle?
And where are you planning to pay for the extra expense of
packing and unpacking these munged pointers? In hardware?
Or in software? Lose, lose.
You seem to be missing my point - this thread is about about possible
implementations of the standard C function "malloc", not anything on
an OS or hardware level. Basically, I was pointing out that one could
use e.g. VirtualAlloc (in Win64) to allocate a pool for each object
size in a particular address range. Then the address of an object
tells you its size (with a little "bit-twiddling") and the pool the
object came from, providing potential space and time performance
benefits - I haven't written such an allocator, so I can't say whether
the benefits pan out compared to other allocation strategies.
And are you sure that two bytes is enough for the block size?
If you're so full of need for a huge address space, mightn't you
also need a wide range of block sizes? Two bytes would
(naively speaking) limit you to 64K objects. Gee, do you
work for Bill?
Larger objects presumably just get allocated from a different region
of memory - this is an optimization for small allocations, since large
allocations tend to occur seldom. In C++ in particular, small object
allocations are very common, and small object (and pool) allocators
are a common optimization (see e.g. Alexandrescu's bit-twiddle-tastic
small object allocator and boost.pool).
And while 64 bits seems like an unimaginable amount of address
space, once you start pecking away at it like this, it doesn't
take long to whittle down to something rather closer to the
imaginable: you are proposing reducing it to a 48-bit space
(are you *sure* you don't work for Bill?). I.e., only 64K times
larger than what has already proven to be too small, as of
several years ago. OS architectures tend to outlast hardware
architectures, if they're any good (or even not!). The designers
of the original Mac may have been correct that nobody would ever
max out the 32-bit address space on a 68000 Mac I, but later Macs
of course approached and then crossed the 4G barrier.
Fortunately, Apple (or *somebody* at Apple) was smart enough to
aggressively redesign the underlying software, rather than start
hanging bags off the side like (here he is again) Mr. Bill.
I'm talking about a drop in malloc implementation. If you run out of
space, or if you don't like the "smell" of this fictional malloc
implementation, just use a different one.
Tom
