From: Nicolas Neuss <neuss@ma...>  20070905 08:16:33

Juho Snellman <jsnell@...> writes: > Nicolas Neuss <neuss@...> writes: > > > The issue you're reporting has to do with the generational nature of > > > the garbage collector. Basically data is being accumulated into older > > > generations, and not getting collected from there. SBCL can't do a a > > > full GC to free up more memory, since that will require N+2*M memory > > > where N is the heap usage before GC and M is the usage after it. > > [Err... That should of course be where N+M for those definitions of N > and M. I was thinking of different ones while writing the formula...] Ah, ok. > > This would mean that (if N=M as in the test function) my data structures > > should be able to use about 1/3 of the available heap, no? If I interpret > > my experiments correctly the limit is lower, something like 1/5 or even > > 1/6. > > I'm not quite sure of what you mean. You can certainly fill up half of > the heap with your own data structure and then successfully run a full > GC. Is the question about running multiple iterations of the memory > consuming code? If so, the answer is what I was trying to explain in > the previous message: the data sets of previous iterations might still > be using up heap in the older generations, even if they are logically > garbage. OK, now I understand also this point. I tried including a (gc :full t) in the loop, and it does remove the problem. Maybe this could also be an option for my actual application. Thanks, Nicolas 