On Friday 11 April 2008 19:05:41 Bob Rogers wrote: > From: chromatic <[EMAIL PROTECTED]>
> The free object list is the reason that compacting/copying collectors > are popular, specifically that all you have to do to find the next > free object is bump the pointer by sizeof (header) and see if that's > still within the bounds of the pool. > > You don't even need the bounds check, strictly. Several popular free > Lisps just blindly initialize the last word of the new object, and if > that segfaults, the allocation is restarted after creating a new pool. > But I don't know if it's really worth it for anything smaller than a > cons (two pointers). I can see that working, but I'm a little leery of catching segfaults in a cross-platform way (and the cost of that context switch... hmm, have to benchmark that), but I'm more worried that there won't be a segfault because the next page happens to be in already-allocated memory somewhere and we're overwriting something else. We have multiple pools of different sizes. > Wouldn't it be better to have the GC trigger after the next X bytes or > objects are allocated, rather than using the end of the pool? The pool > boundary seems pretty arbitrary to me. Possibly. I'm not sure how that interacts with the three-color incremental scheme in the PDD, though. We could go for the low-latency system or a very conservative system or a high throughput system, but I need to think more about the implications of the documented system. > Weren't we just recently having a problem with special treatment for > constant PMCs? Full support for magic flying ponies is gonna cost you, > and it'll probably be in terms of reliability. I know, but once in a while refcounting has its advantages.... -- c
