On Aug 27, 11:59 am, Nils Bruin <nbr...@sfu.ca> wrote:
> On Aug 27, 9:07 am, rjf <fate...@gmail.com> wrote:
>
> > Let GMP do its own memory allocation. After Lisp has itself allocated
> > a structure S with a pointer to a GMP-allocated object, it knows what
> > to do: either S is
> > used or not, determined by a garbage collection. When S is
> > determined to be not used, mpz_clear or whatever, is called. This
> > actually may not happen at the next garbage collection, but at the one
> > after.
>
> This is roughly what ECL was doing before, but they made sure that GMP
> would allocate the limbs on the GC managed heap.
This is exactly the opposite of what I was doing, not roughly the
same.
I let GMP do its own allocation. But then I was not using GMP for
all the arithmetic
in the Lisp. I was just using it for special occasions when I had
some reason to
believe that ginormous numbers were needed.
>That way they saved
> themselved having to call mpz_clear but more importantly, the GC would
> have a proper view of the memory usage (and hence can trigger a GC
> when appropriate).
Maybe this would be appropriate if GMP did ALL the bignum arithmetic.
>
> If you let GMP allocate the limbs outside of the GC managed heap, they
> are outside of the view of the GC, so the GC gets a very skewed view
> of memory usage.
Right, in my scenario, the Lisp system would not know about bignum
allocations. But most
Lisp systems keep track of different kinds of memory -- e.g. arrays,
conses,
symbol tables, numbers. If you run out of bignum memory, you (or GMP)
can allocate more. If GMP is storing garbage, it will soon be
discovered...
> If your GC is really eager to collect garbage, you
> might be OK, but otherwise you run the risk of ending up with a lot of
> garbage allocated on the malloc heap while the GC thinks there are
> only a bunch of structs consisting of 2 ints and a pointer lying
> around.
Well, if the GC is instrumented properly, it would notice that no one
is using those structs, and mark them for destruction. The
destruction would consist of calling mpz_clear.
The code from my lisp looks like this:
(defun alloc-gmpz() ;; provides an empty gmp object for us to use,
init to zero
(let ((inside (make-array 3 :element-type
'(signed-byte 32)
:initial-element 0)))
(mpz_init inside)
;;this next line sets up lisp to keep track of this object.
;;it sets up gc for what to do later, in case this object
;;is not accessible: the entries in the array "inside" will go
away.
;;the array "inside" as well as the gmpz header will be gc'd
later.
(schedule-finalization inside #'mpz_clear)
(make-gmpz :z inside)))
perhaps ECL does not have something like schedule-finalization. I
think this is present in
CMUCL, SBCL, Lispworks, and AllegroCL, at least.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
