Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès escreveu: > Can you be more specific about this? Off the top of my head: incorrect indentation, missing spaces around brackets, and more importantly comments (see (standards.info)Comments). > See below - note that the old .scm file was pretty much broken, as it > was using gc-live-object-stats which is only accurate just after the > mark phase. Hmm, `gc-live-object-stats' may return information from the previous cycle, but it shouldn't be *that* accurate, should it? Interestingly, head-before-your-changes and 1.8 end up with `cells-allocated' greater than `total-cell-heap', which I guess isn't intended (`cells-allocated' and `scm_cells_allocated' are really the total number of cells allocated since the last GC, right?). In the case of 1.8, it's only slightly greater; in the case of head-before-your-changes, it's more than 80 times greater. That does seem to indicate brokenness... > The problem is that the previous state of the GC was very much confused > with contradicting definitions within the code of what was being kept as > statistics. This is problematic since the allocation strategy (should > I allocate more memory?) was based on these confused statistics. Which statistics were confused exactly? Can you pinpoint the part of your patch that fixes statistics computation? Otherwise, I find it hard to say whether it's actually "fixed". > It's still somewhat kludgy - especially the way that gc-stats is > constructed is asking for trouble. We should really have a scm_t_gc_stats > struct and use nice OO patterns for dealing with that. What would you think of using the Boehm et al. GC? I'm willing to import the BGC-based Guile branch into Git when time permits, so that we can compare them. Thanks, Ludovic.
