Agree .
Why a sub heap and not a seperate heap ? Or is it because its still under the GCs nominal control ? Why do we need ARC at all in the automatic system , since It can be slow for the non single threaded cases. ? Is it to manage separate long lived regions , and if so why is the pauseless GC not doing it on a separate heap? In terms of relieving the GC regions , type aware heaps seem more promising . Actually I can see a case where analysis shows there are few references created and hence the cost is not high so you can move them from the GC but is this ( the frequency of references not allocations) intended in the region analysis that was planned ? Not many type safe languages that allow these sort of things done in a lib .. Ben On Mon, Aug 5, 2013 at 6:11 AM, Jonathan S. Shapiro <[email protected] <mailto:[email protected]> > wrote: I want to step back from the GC/Regions discussion to point out a couple of things. We're dealing with two very distinct goals here: 1. Memory safety 2. Reclamation of memory with acceptable pause bounds The only issue that I really feel strongly about in this is the first one. The second one, to my knowledge, simply doesn't have a universal solution. GC is a means to the first goal, and in some cases the second. Regions are an occasionally useful optimization on that means. Regions are particularly important for mostly-allocation-free libraries. But these aren't the only mechanisms, and it is reasonable to examine compromises on the second goal. Such as: * Deferring reclamation (regions) * Failing to accomplish some reclamation (cycles in ARC-based schemes) * Deferring ARC cycle collection to a backing GC, accepting temporary heap leaks as the cost of this practice. * Type-aware heaps using explicit free, such that type-safe aliasing with allegedly, but not provably non-live pointers might occur. * Linear typing, which can be viewed as a form of ARC-at-compile-time * Linear borrowing (to coin a term) which allows us to go from mutable to deep-frozen and back to mutable DAGs or DCGs in some cases. All of these choices, and probably others, are appropriate for some programs. I'm not taking a position on which ones should be used for a given program. Some of them can be built as libraries. Those, in my view, should not be embedded in the language. Of these, I personally think that ARC and variants of linear typing are the most promising tools I can see in the near term. In several cases, the thing I would really like to be able to distinguish is some notion of a "sub heap". Specifically, I'd really like to be able to say "this here reference slot that lives in sub-heap X will always point to some other object in sub-heap X. If we can get to that, then I think we can solve the cycle problem in many cases. _______________________________________________ bitc-dev mailing list [email protected] <mailto:[email protected]> http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
