Re: [Gcl-devel] Re: TMP_ALLOC in mpn_mul_n

[Camm Maguire]

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