Abdulaziz Ghuloum <[email protected]> writes: > On Oct 2, 2009, at 1:42 PM, Andreas Rottmann wrote: > >>> 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]. >> >> [0] >> http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Memory-Blocks.html#Memory-Blocks > > I don't see how this solves the same problem (it appears that this > actually solves the problem that you already solved by using a > guardian and a gc hook). > I don't think so, see below.
> A hack around the problem above is to create a bytevector of size > N every time you malloc a BLAS vector of size N, and that ensures > that the GC will trigger at the same frequency as before; but this > is not clean since it's adding needless garbage. All the other > pages that I've read so far seem to be variants of the same hack > (I mean technique). > IIUC, this exactly the purpose of these `register_collectable_memory' calls: they are intended to make the garbage collector run at an earlier point in time than it would have run otherwise, just like your hack, but without actually allocating anything. >From a cursory look, this is also essentially what the .NET and OCaml APIs linked to by Patrik and Ronald do. Regards, Rotty
