Additional memory handler features.

[Niels Möller]

"David M. Warme" <David at Warme.net> writes:

>> But I'm not ocnvinced this level of granularity makes sense. Which
>> problem does it solve?
>
> Limb arrays have the potential to receive special treatment by the
> memory manager.

Agreed. What I asked was what problem is solved by finer granularity
than memory with and without pointers. I kind-of dislike adding very
gmp-specific arguments to the allocation functions, so I'd be happy to
see a *concrete* use case where it solves a real problem.

> Good design on the part of the GMP development team
> has resulted in the existing GMP custom memory management
> function pointers that always explicitly pass the current size, so that
> this implicit address-to-size mapping (and its corresponding overhead)
> is unnecessary.

I believe this design was mistake, and it is under reconsideration. See
https://gmplib.org/list-archives/gmp-devel/2012-January/002161.html.

> a memory
> manager could also make use of the fact that there is one-and-only-
> one permanent reference to each limb array -- namely by the mpz_t
> or mpf_t object that "owns" the limb array.

Right, it's desirable that the gc is made aware of all mpz_t objects.
But it's not obvious that additional arguments to the allocation
function is the right way to arrange that. The cases I'm aware of are
gmp bindings for languages with automatic mamory management (e.g., guile
or pike). And there, the natural way to arrange that is to have wrappers
around mpz_init and mpz_clear that registers all long-lived gmp objects
with the gc.

> The other reason concerns memory lifetime.  The stack temporaries
> tend to have LIFO behavior with respect to allocation and freeing.
> This is another attribute that a memory manager could exploit -- if
> indeed it had any way of knowing that the request was for a stack
> temporary, rather than for a longer-lived (or less predictably-lived)
> object.

I agree a special stack allocator could have a place here (in
particular, if for some reason running with a very small execution
stack). And it could be done internally in gmp.

But also note that small allocations are typically done on the execution
stack, with alloca, and that for larger allocations, the computational
cost of computing the limbs stored there is vastly larger than the
allocation overhead, making the latter negligible.

> One of the difficulties with GMP is that the limb arrays associated
> with mpz_t (and therefore mpq_t) objects *never* decrease in
> size, unless the user explicitly calls mpz_realloc2().

In case requiring explicit calls to mpz_realloc is difficult for real
applications with "intermediate expression swell", we should consider
doing that automatically in gmp, e.g., whenever size < alloc / 3 or so.
And as you note, a gc can also do this automatically if it is told which
mpz_t objects exist.

Regard,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.