Additional memory handler features.

[David M. Warme]

You seem already convinced there are potentially significant benefits
for handling larger, off-stack "temporary" heap allocations differently
from other heap allocations.

> ... a largish memory area with only start address, size, and stackpointer
> needed to keep track of the allocation state, ...

One set of these per thread.

   Then you need a linked-list of blocks, for the case where your "largish"
   initial block turns out to be too small.  (It is not feasible to use only
   one block and to realloc it when it needs to grow -- even if you copied
   the data, there would be pointers into the old block lingering on the
   stack, with no way to find and update them all.)

   Consideration should then be given to freeing of said blocks upon return,
   and the main block might also be re-sized (bigger or smaller) when it
   transitions from empty to non-empty or vice versa...

My point is that this is a slippery slope.  Once you start down the path,
new layers of complexity arise.  Does this complexity belong inside of
GMP?  No!

The Unix Philosophy urges GMP to do one thing, and do it well -- high
precision arithmetic.  In the other areas (e.g., memory allocation,
exception handling), it should defer to other, smarter entities.  This
means that GMP should provide interfaces that assist, rather than hinder
such smarter entities.  The current interfaces hinder.  More precisely,
they do not provide enough information to assist smart memory managers.

GMP is a very special animal.  It crunches huge numbers very efficiently.
But it can also crunch small numbers very slowly, compared to "int" or
"double".  It can consume huge amounts of virtual memory.  It can use
this memory very efficiently (mpf_t's, which never grow), or very
inefficiently (huge numbers of over-sized limb arrays).  You may have
a nice long array of mpz_t objects, with good locality, but with the
corresponding limb arrays scattered all over the virtual address space,
leading to a huge TLB miss rate or high cache line turnover, even on
simple sequential loops down the array.  There are many opportunities
for a smart memory manager to help smooth out these wild variations
in behavior.

One key aspect of GMP is that it only uses memory in a small number of
distinct ways.  Any sufficiently smart "GMP aware" memory manager will
want to know which case it is dealing with.  The current interfaces
provide no clues.

> Do you have any examples of libraries with custom allocation functions
> which you think think gets this right?

Excellent question!  Unfortunately, the answer is no.

David