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] |
Greg Harvey wrote: > I was thinking more along the lines of a per segment list that > contained the possible generations this segment could have objects > pointing to. For example, when we're collecting generation 2, we only > have to scan over segments that have generation 2 in their > possible_pointers list. Then, we can take the time to jump through the > segment, checking for pointers (if we don't find one, we beat up the > segment for lying to us, and remove 2 from the possible pointers > list). A lot of this depends on the implementation of the write > barrier, though I think it could work well with this. I see. Instead of a list, how about a bit map? You don't have to worry about duplicates and it takes a fixed amount of storage. > > What's SCM_ASSIGN? My (rather outdated now) sources don't mention it. > Possibly what will be required in c code with a write barrier, to do > the appropriate calculations. > > Won't the required call to scm_gc_mark handle this? > > { user smobs with pointers } > Not for alerting the write barrier of the location of possible > pointers. We can't catch these otherwise, since they're outside the > heap. Well, they would normally be marked by a full scan; your point is that they may not be marked by a particular generation's scan. This is bad news. Basically, smobs are like a heap segment -- we need some sort of write barrier to record pointer stores into them or we need a way to trace all of them and force their mark functions to be called (ie. as if they were in the root set.) A revised scm_gc_mark could ignore calls with pointers into the wrong generation. Getting a list of all smobs might require an API change; so would a call to a write barrier function. Would everyone tolerate this? Dale.