Re: GUILE_MAX_HEAP_SIZE

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <address@hidden> 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.