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


Greg Harvey <Greg.Harvey@thezone.net> writes:

> It can be fairly expensive when the gc marks are moved off of the
> objects and into separate heap cells. Currently, it's able to get at
> those marks by doing a few shifts and &'s with the location of the
> cell. With variable ncells, tho, it means that setting a gc mark also
> requires looking up the segment that the object is in, and figuring
> out the correct shifts and masks to get at the mark locations. 
> 
> As it is, I don't think that the current gc will work reliably with
> ncells != 1 (and it certainly isn't easy to get an object of the size
> you want). For objects that would benefit from 4 words (I'm thinking
> objects that would otherwise have to do a small malloc), it might be
> better to have a small copying heap to do allocation from. This still
> wastes a pointer word, but would probably perform better than having
> to malloc the space, and allows the cell heap to stay uniform.

OK, then I think you can safely drop the ncells != 1 code.  (Because
I'm the only one among the "developers" who is mad enough to want to
keep it.)

(BTW, if you keep th GC bits separately, it seems like the sweep can
 be made cheaper by testing entire words of GC bits at a time.  Do
 you use such an optimization?)