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]

Re: In the search of heap enlightenment...


Michael Livshin <cmm@post.tau.ac.il> writes:

> Mikael Djurfeldt <mdj@nada.kth.se> writes:
> 
> > That means that we can eliminate extra indirections and extra memory
> > and extra overhead for initialization of pointers on whole bunch of
> > places.
> > 
> > E. g., if we represent subrs with this new cell type, we can store
> > their names and properties in a more reasonable way than currently.
> 
> It could also be used to represent flonums, so they won't need to be
> malloced.  Cool.  Oh, and it's great for indirect records too.

And small strings :)

> I have one question, though.  I think I'll know the answer from
> looking at the code by tomorrow, so don't answer if it requires any
> effort.  The question is: do different types of cells go in different
> heaps?  If so, why?

Well, different segments anyway. This is partly because, with the
freelist approach, we can't treat both types of cells the same (and
once things get fragmented a bit, allocating a new 4 word cell with
one freelist would become a real hassle); but mostly because it's
easier ;). This way we always know, given a heap segment, the exact
size and alignment of cells, so we can optimize a few bits (sweeping,
currently); if we had mixed cells, we'd always have to look at the
type of the cell, so we could decide if it were 2 words or 4 words.

We also need to know this during the conservative sweep (see the
change to scm_mark_locations), so that we don't end up marking into
the middle of a 4 word cell (though maybe this should be changed to
mark the cell itself, since it's likely that a reference into the
middle means that someone's holding a pointer and doesn't want the
object to die).

It would probably be possible with all cells in the same segments, but
wouldn't gain anything over keeping them separate (except a lower
initial memory usage, but we'd probably end up allocating more in the
mixed scheme, since it's likely going to get harder to find 4 word
cells as the runtime grows). The amount of extra work would probably
be brutal, though.
 
-- 
Greg