> > The main problem with ARC is cycles. What if, through regions, we can > ensure that all cycles are implemented by borrowed pointers? I'm not sure > that it works in all cases, but it's one more way to narrow the problem > space.
In a sense, my linked-boxes strawman *is* effectively doing this, because it assures *all* interior pointers are borrowed. Those box-to-box references could be ARCed instead of GCed if this is material. However, this seems a small issue compared to ultimately handling reclamation/coalescing. On Fri, Aug 2, 2013 at 12:35 PM, Jonathan S. Shapiro <[email protected]>wrote: > Effectively, this is a mechanism to implement typesafe-managed-manual >> memory techniques within a GC system while hinting to the GC that doesn't >> need to frequently concern itself with the details inside the boxes (see >> below). >> > > Almost, modulo my comment about coalescing ranges within the allocator. > I'm looking at this from a different vantage point so for me automatic/assisted coalescing does not seem essential, it's merely nice to have. My systems-view says as long as I can do extra work as a programmer/designer to get closer to the performance goal I want, I'm happy. Which means I'm 100% happy to write a manual manager for some subset of data, and 100% happy to either accept fragmentation, or manually coalesc if I want to free a sub-block. This is better than I can do today with managed systems AFAIK. ----- As for automatic-coalescing, once we go there, we're basically talking about a compacting collector which allows manual "free" by loosening the no-alias restriction and using separately typed-pools (both for allocation and compacting destinations) -- dove-tailing into your post about aliasing. Maybe that is a reasonable and more general way to approach it. On that note, I think alias-safety could be checked with less performance impact than barriers or ARC, because by far the most common branch would be alias-match. However, in itself this approach doesn't actually address memory reclamation.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
