[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: TMP_ALLOC in mpn_mul_n
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Re: TMP_ALLOC in mpn_mul_n |
Date: |
16 Aug 2002 19:05:46 -0400 |
Greetings, and thanks for your helpful reply!
Kevin Ryde <address@hidden> writes:
> Camm Maguire <address@hidden> writes:
> >
> > Now I understand that gmp probably wants to use the heap by default
> > for those really large 'bignums',
>
> For temporary workspace normally alloca is used, but when an operation
> is going to be slow anyway then malloc is used to avoid overflowing
> the stack unnecessarily, as for example the toom-cook in mpn_mul_n.
>
Understood -- thanks!
> > but would it be possible to provide
> > a runtime option to use alloca and the C stack here? Either via a
> > separate function, or a routine setting an internal variable, similar
> > to the way in which one can set the (non-stack) allocation functions
> > in mp_set_memory_functions?
>
> Maybe. But perhaps it'd be possible to give mp_set_memory_functions
> routines with normal C semantics. I understood the underlying problem
> with gmp in gcl was that gmp couldn't cope with memory blocks being
> moved around by a garbage collect that happened within a malloc or
> realloc.
>
1) It is of course possible to do as you suggest, and protect all
possible references to gmp library calls with a redirection of
memory allocation to some temporary static space, but this will
require much work, and we're not likely to have the resources
anytime soon. Beyond which, at least from gcl's perspective, it
*really* complicates the memory management.
2) Anyway, all of that is gcl's problem and not gmp's -- but what
about other systems using garbage collection? The Boehm collector
is becoming more popular these days for example, and it relies on a
redirected malloc as well. Wouldn't gmp prove more useful for such
systems as well if a tmpalloc option was available?
3) I must confess that I have not examined in detail the call path
used in gmp internally, but rather relied on Dr. Schelter's
apparent conclusion that gmp was garbage collection safe save for
the one patch he made. Of course, I need to see this for myself at
some point. Do you know of any areas off hand in which gmp would
assign a pointer variable, do some allocation, and then access the
original variable which then could be no longer valid? gmp doesn't
save addresses statically anywhere, does it? In any case, it is
entirely possible that even if gmp does do the former, as long as the
address in question is held in a local variable on the C stack,
gcl's garbage collector will find and 'mark' it.
4) It sounds as if you might be aware of some prior conversation with
Dr. Schelter on these points. Is such a conversation archived
anywhere?
Take care,
>
> Incidentally, don't forget there's a gmp configuration option in the
> other direction. --disable-alloca means don't use alloca at all, but
> malloc instead (or rather the mp_set_memory_functions routines). Not
> sure if anyone uses that unless that have to (ie. systems with limited
> stack space).
>
Thanks for pointing this out! What we're likely to do in the short
run is to compile the patched file alone, link it in explicitly and
the gmp dynamically, and rely on the weak symbol behavior to include
the patch. On Windows, we'll have to build and statically link our
own version for the time being. Do you see any problems here?
Thanks again very much for your helpful replies!
Take care,
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- Re: [Gcl-devel] Re: TMP_ALLOC in mpn_mul_n,
Camm Maguire <=