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] |
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