On Dec 29, 2003, at 11:48 AM, Dan Sugalski wrote:
As I see it, it's really the allocation that is more complicated with
a mark-and-sweep collector (since you have to search for a
correct-sized free chunk, efficiently)--the collection itself is the
easy part. Actually, it seems like this is just
At 11:28 AM -0800 12/29/03, Jeff Clites wrote:
On Dec 29, 2003, at 8:13 AM, Dan Sugalski wrote:
2) We need a more traditional, non-moving GC as an alternative to
the copying collector. A modified mark & sweep'd be fine, but as
it'll be living behind the API it doesn't much matter.
This is really
On Dec 29, 2003, at 8:13 AM, Dan Sugalski wrote:
2) We need a more traditional, non-moving GC as an alternative to the
copying collector. A modified mark & sweep'd be fine, but as it'll be
living behind the API it doesn't much matter.
This is really only for the chunks of memory backing strings
Well, two tasks actually.
What with threads coming in, some of the limitations of a copying
collector are becoming very apparent. While it's really nice, and
just feels really cool, in the single-threaded case, neither nice nor
cool justifies potentially massive headaches and synchronization
i
