This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
mike@olan.com (Michael N. Livshin) writes: > Mikael Djurfeldt <mdj@nada.kth.se> writes: > > > mike@olan.com (Michael N. Livshin) writes: > > > > > Just looked at how scm_weak_vectors are handled. It's nice and fast > > > and all, but isn't calling `realloc' during `scm_gc_mark' considered > > > harmful? > > > > Why? > > What if the very reason to collect garbage was that there is no memory > left? Oops! Now I understand your point. You're hinting that GC is used for reclaiming space and that this is especially good to do when we're out of memory... fascinating idea, I think you're right! :) Actually, in Guile, it can't be the immediate reason. GC is initiated when we're out of pairs. Failing mallocs usually lead to error. But I agree that it is unwise to allocate much space during GC. I guess we could let the creation and destruction of objects control the size of the vector, or we could introduce some near-memory-limit protection code which releases some large pre-allocated block back to the system when mallocs fail. The latter "solution" could improve near-memory-limit performance in lots of other respects as well. However, nowadays I think it is very unusual to hit the limit of virtual memory. The main task of the memory management system must be to minimize memory usage rather than to handle the limit situation. I don't know how others feel about this, but I think the current scm_weak_vectors solution is OK for now. > curious in Rishon-le-Zion, (Please enlighten this un-cultural Swede. What is "Rishon-le-Zion"?) /mdj