On Fri, Aug 2, 2013 at 1:20 PM, David Jeske <[email protected]> wrote:
> 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. > I think that's backwards. I think what you want is for the pointers that * retain* the boxes to be ARC pointers, and the pointers *between* the boxes to be borrowed or weak or intra-region or some such thing that doesn't need to be traced. If that is the case, then the ARC pointers handle the reclamation. > 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. > So you might think. The Achilles heel in Adve's proposal is that you can't change the type of an object in the malloc arena. Not just the size. The type. So there are various causes of fragmentation in this scheme, and an incremental background cleaning agent is probable helpful to learn when arena chunks are truly unreferenced. 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. > Yes. Though when I spoke of automatic coalescing, I was thinking in terms of something that would either run strictly incrementally (with tightly bounded microsecond-scale pauses) in the background or something that would only run when invoked explicitly by the program. I haven't thought about which way to go, and I think it's probably something that needs to be informed by practical experience. > 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. > Alias safety is *very* hard to check. It requires whole-program liveness analysis. As to memory reclamation, it's worth remembering that free() doesn't do that either. Calling free() doesn't really reduce your memory footprint. All it does is make existing portions of the arena available for use by malloc(), There *are* implementations that unmap the backing store of unreferenced portions of the arena, but it's never been clear to me how often that capability is actually used in practice. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
