[Gcl-devel] GCL and GMP (was Re: [Axiom-developer] Re: Bug#263991: axiom: wrong calculation ofsqrt(2.))

[Camm Maguire]

Greetings!  I think I have fixed this issue once and for all, and
would like feedback.

Dr. Schelter originally integrated gmp into gcl with a single patch to
the gmp source with the intention of allowing gcl_gmp_alloc return
memory blocks which could be moved around on garbage collection.  This
is a *big* performance win, so foregoing this is not a particularly
practical option.  Further along this vein, the gmp docs state that
they can store pointers to other blocks in allocated blocks, which
will (or should at least, never yet detected) foil conservative
garbage collection strategies like ours.  So the bottom line is we
want to make sure that the garbage collector is never called from
within a gmp allocation, whether or not that allocation is
relocatable.  

The gmp docs state that the code cannot handle user allocation
functions which return NULL on out of memory, for example.  This is
too bad -- wonder if that could ever be fixed.  The docs also state
that a longjmp strategy, i.e. jumping back to the beginning of the
call, calling the garbage collector outside gmp, and then retrying the
gmp call, will have undefined consequences, but that 'this might
change someday'.  Nevertheless, this seems our best option at present
:-).  

The only alternative is to try to patch the source wherever gmp
allocates temporary memory on the heap to use alloca instead.  The
problem with such a strategy is that it presents a moving target as
gmp is developed.  We default to a dynamic link against gmp with the
patched function(s) supplied locally.  Apparently Dr. Schelter
overlooked at least one needed patch, or the pathway was inadvertently
made possible some time ago, but in either case, this shows the
difficulty with this strategy.  

With the longjmp option, we can forget about compiling any gmp code at
all when the user has libgmp3-dev installed, perhaps even forgoing the
time-consuming configure.  I'm sure Mark Murray would be happy to hear
this.  

Just done some preliminary testing, and it fixes this issue and
appears stable thus far.  Here is an example of the wrapper:

#define MEM_GMP_VOID_CALL(n_,a_,b_...) \
   EXTERN_INLINE void Join(m,a_)(Join(P,n_)(b_)) { \
           jmp_gmp=0;\
           if (setjmp(gmp_jmp))\
              GBC(t_relocatable);\
           if (jmp_gmp++>1) \
              FEerror("gmp jmp loop in" #a_, 0);\
           a_(Join(A,n_)());\
           jmp_gmp=0;\
   }

#define MEM_GMP_CALL(n_,rt_,a_,b_...) \
   EXTERN_INLINE rt_ Join(m,a_)(Join(P,n_)(b_)) { \
           rt_ tmp;\
           jmp_gmp=0;\
           if (setjmp(gmp_jmp))\
              GBC(t_relocatable);\
           if (jmp_gmp++>1) \
              FEerror("gmp jmp loop in" #a_, 0);\
           tmp=a_(Join(A,n_)());\
           jmp_gmp=0;\
           return tmp;\
   }

MEM_GMP_VOID_CALL(3,mpz_add,mpz_t,mpz_t,mpz_t)
....
#define __gmpz_add m__gmpz_add
....

and then in the alloc function:

            if (jmp_gmp)
              longjmp(gmp_jmp,jmp_gmp);
            else
              GBC(t_relocatable);


If I could enter a wishlist request to the gmp people, it would be
that

1) An option be provided where temporary memory could always be at
   least attempted on the stack first.
2) An error recovery pathway for user allocation functions returning
   NULL.  This would allow us to replace the longjmp with a simply
   trap of the error exit, collect the garbage, and retry.  (Don't
   know if setjmp carries much more overhead, but...)
3) An explanation of what kind of 'undefined consequences' the longjmp
   could have, and perhaps eventually making things safe for this
   possibility in the code.  Is there a problem in single-threaded
   only code?

This is likely important enough to go out soon.  Thoughts on this from
GCL developers most appreciated.


Take care,


Camm Maguire <address@hidden> writes:

> Greetings!  This is GCL's fault.  A workaround at present is:
> 
> )lisp (set-gmp-allocate-relocatable nil)
> 
> If you wish to make this permanent follow with
> 
> )lisp (si::save-system "/tmp/axiom")
> mv /tmp/axiom /usr/lib/axiom-0.20040705/bin/AXIOMsys
> 
> I will track this down and fix this in the next GCL release.  It
> would be helpful if someone who builds axiom with GCL's local copy of
> the gmp source statically linked in  (i.e. ldd on AXIOMsys does not
> show a gmp link) could report whether the issue persists.  
> 
> For those who want to know, we have to patch gmp in one place to allow
> bignums to be relocatable, which is a tremendous speed advantage.  By
> default on Debian, we dynamically link against external gmp, and it
> appears that the latest version has an additional place where a patch
> is now needed.
> 
> Take care,
> 
> William Sit <address@hidden> writes:
> 
> > > Heiko Scheit <address@hidden> writes:
> > > [snipped]
> > >   echo "digits(DIGITS); sqrt(2.)" | axiom
> > > One can see that for
> > > > DIGITS=121278-121280 the result is not correct.  For 121290 digits the
> > > > result is OK again.  As reference the output of Mathematica is given
> > > > in the last row.
> > > >
> > > > DIGITS    |         result
> > > > --------------------------------
> > > > 121275    |    8347436383 149
> > > > 121276    |    8347436383 14897
> > > > 121277    |    8347436383 148974
> > > > 121278    |    8347436382 1263421
> > > > 121279    |    8347436382 9853356
> > > > 121280    |    8347436383 114184622
> > > > 121290    |    8347436383 1489743406 4670264
> > > > ---       |    8347436383 1489743406 467026400   (Mathematica output)
> > > [snipped]
> > 
> > I verified that NAG 2.3 version gives correct result for 121278-121280 
> > (RedHat
> > 9.0, i386 Pentium II (MMX) simulated on a Mac OS 10.2.8 using Virtual PC 
> > 6.01).
> > 
> > 121278       8347436383 1489743
> > 121279       8347436383 14897434
> > 121280       8347436383 148974341
> > 
> > William
> > 
> > -- 
> > William Sit
> > Department of Mathematics..............Email: address@hidden
> > City College of New York..........................Tel: 212-650-5179
> > Convent Ave at West 138th Street..................Fax: 212-862-0004
> > New York, NY 10031............Axiom, A Scientific Computation Sytem
> > USA..........................http://www.nongnu.org/axiom/index.html
> > 
> > 
> > 
> 
> -- 
> Camm Maguire                                          address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah