camm at enhanced.com
Fri Dec 9 17:04:56 CET 2005
Torbjorn Granlund <tege at swox.com> writes:
> Joe Keane <jgk at jgk.org> writes:
> I think the TMP_ALLOC is more trouble than it's worth.
> The alternative is, in every case, have a modest fixed-size local array;
> use that, or `malloc' if needed, later `free' if needed.
> This seems error prone, and would require massive changed of the
> sources. I have a better idea:
> Define TMP_SMALLOC and TMP_BALLOC, the former doing exacly what
> TMP_ALLOC does today with --enable-alloca, and TMP_BALLOC using
> the stack unconditionally, i.e., doing what TMP_ALLOC does today
> with --enable-alloca=malloc-reentrant.
> TMP_ALLOC is changed to choose TMP_SALLOC under a threshold and
> TMP_BALLOC else.
> This requires minimal changes, the only ones required are to
> gmp-impl.h, with optional changes at points where it is known the
> allocation is large or small.
> And you know what? It is already implemented and will come in
> GMP 4.2. :-)
This level of flexibility sounds great, thanks!
Just wanted to weigh in as GCL maintainer, stack allocation within gmp
is almost always a win for us. It is still the case on most 32bit
machines that the heap is effectively limited to 1Gb by the default
shared lib placements commonly in use, leaving nearly twice as much for
stack(!). Even if one compiles statically, working with more than a
2Gb heap often has significant limitations, in which case one still
has at least 1Gb of stack in principle.
At one time, we were quite sensitive to these internal details, but
now we are reliably independent as we control garbage collection in a
special wrapper around gmp functions (bignum bodies are much more
efficiently handled on relocatable pages). Still, avoiding the memory
management system entirely with stack allocations will always be even
> gmp-discuss mailing list
> gmp-discuss at swox.com
Camm Maguire camm at enhanced.com
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
More information about the gmp-discuss