On Oct 2, 6:42 am, Andreas Rottmann <[email protected]> wrote:
> Abdulaziz Ghuloum <[email protected]> writes:
> > On Oct 1, 2009, at 8:31 PM, Andreas Rottmann wrote:
>
> >> Given the above, you have two options to make the reclamation happen
> >> automatically: Either place a call to `collect-blas-vectors' into
> >> `make-blas-vectors', or register `collect-blas-vectors' with the GC,
> >> which is a recently-added feature[0]. You can read more about
> >> guardians in the paper "Guardians in a Generation-Based Garbage
> >> Collector", by Dybvig et al. [1].
>
> > The only little problem that I see is that making many BLAS vectors
> > quickly could potentially run out of memory before the GC triggers.
> > (because a BLAS vector of N bytes will only use fixed few bytes of
> > Scheme data, and it will take lots of these to cause a GC) I don't
> > have a clean solution to this problem. Any ideas?
>
> Guile approaches this problem by having API that allows informing the GC
> about potentially collectable memory, see
> scm_gc_register_collectable_memory() and
> scm_gc_unregister_collectable_memory() in the manual[0].
>
This discussion has been most helpful. Thank you all!
One more question. Is there any reason not to implement a blend of
these approaches?
Specifically, could I (for example):
* Register collect-blas-vectors with the GC, thereby ensuring that
GC happens at least semi-regularly.
AND
* Call collect-blas-vectors from within make-blas-vector.
To avoid the overhead of a full sweep of the guardian on every call,
I could (for example) trigger it every 10th allocation (or
automatically
determine when to trigger based on the amount of outstanding memory
allocated).
That might give me the best of both worlds.
In any case, thanks again for your help. I'll play around and figure
it out!
-- David
