Hi :)
Nice investigation! Perhaps slot-allocation should track live variables
using something that's not bigints, but who knows.
On Wed 05 Feb 2020 17:29, Ludovic Courtès <l...@gnu.org> writes:
> /* The next three functions (custom_libgmp_*) are passed to
> mp_set_memory_functions (in GMP) so that memory used by the digits
> themselves is known to the garbage collector. This is needed so
> @@ -237,19 +227,20 @@ finalize_bignum (void *ptr, void *data)
> static void *
> custom_gmp_malloc (size_t alloc_size)
> {
> - return scm_malloc (alloc_size);
> + return scm_gc_malloc (alloc_size, "GMP");
> }
>
> static void *
> custom_gmp_realloc (void *old_ptr, size_t old_size, size_t new_size)
> {
> - return scm_realloc (old_ptr, new_size);
> + return scm_gc_realloc (old_ptr, old_size, new_size, "GMP");
> }
>
> static void
> custom_gmp_free (void *ptr, size_t size)
> {
> - free (ptr);
> + /* Do nothing: all memory allocated by GMP is under GC control and
> + will be freed when needed. */
> }
I think this makes sense to me as a short-term fix. The down-side is
that limbs can alias Scheme objects.
In the long-term I think we should be representing bignums as
pointerless objects whose first word is the tag and a word count,
followed by inline "limbs" (in the sense of
https://gmplib.org/manual/Nomenclature-and-Types.html#Nomenclature-and-Types).
Generally we can use the low-level API to work on these
(https://gmplib.org/manual/Low_002dlevel-Functions.html#Low_002dlevel-Functions),
and if we need to use mpz_t, we can easily create an mpz_t that points
to these values.
Cheers,
Andy
