On 5 August 2013 11:24, David Jeske <[email protected]> wrote: > > On Aug 4, 2013 2:50 PM, "Jonathan S. Shapiro" <[email protected]> wrote: >> Yes. This "one, maybe two" problem is an example of a region whose size is >> not statically boundable. Such regions may indeed need GC, though it's at >> least a very fast, generational-style GC that does not have to consider >> pointers from tenured space to new space. > > ... What is the difference between this and young generation scavenge? Seems > the same to me. > > To me it seems we are discussing (a) statically sized regions... Which are > already handled well by the stack, and (b) dynamic regions which need GC > that are already handled well by young generation scavenge. > > If objects are being tenured too fast..We can prevent promotion for > objects/regions only referenced by stack frames. > > What region win am I missing?
For starters, the fact that regions infer the difference in the common case. You can tell which regions are statically sized, and which are captured, from the latent region effect of the function. Even for those not statically sized, you can usually infer a point where you can explicitly de-allocate the values within the region. In the 'return a list' example, you can use the region variable of the return value to infer the lifetime of the result list, even inserting a free() call when it is unused. The heap that a region is allocated into may not be the GC heap; it usually isn't. Simply: region systems infer static lifetimes for most values. This does not mean that a region needs to be a fresh, distinct GC heap. They can be implemented in that way, and you can determine at the level of region allocation if that is necessary (due to the latent effect of the body), but in the common case, even in the presence of dynamically sized regions and certain types of weakening, the region system can allocate into an *explicitly managed* heap and insert free() calls in the appropriate locations. That it doesn't /always/ work means you usually add GC (or report a warning about a memory leak). However, being able to introduce regions to dynamically describe your heap layout is also a useful technique that works along with the region system. This appears to be what you're talking about. It's also a useful thing to have, I guess, when that region may end up larger than the usual eden space, and being explicitly demarcated could be useful. But it's not, in general, what we are talking about in terms of regions. Usually regions let you allocate things on the stack, or infer free() for you, there is no GC involved for most code. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
