<br><br>
<div class="gmail_quote">On Tue, Aug 4, 2009 at 2:49 PM, Simon Marlow <span dir="ltr">&lt;<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>&gt;</span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>
<div></div>
<div class="h5">On 04/08/2009 13:33, Sam Martin wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Sounds like region inference to me.<br>(<a href="https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference" target="_blank">https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference</a>)<br>
</blockquote><br>Thanks, yes, that&#39;s exactly what I had in mind.<br><br>Is anything like this is done in GHC?<br></blockquote><br></div></div>Not at the moment, no.<br><br>Bear in mind that with generational GC, allocating memory that quickly becomes garbage is quite cheap.<br>
</blockquote>
<div> </div>
<div>Speculation time... I have no real basis for this, and I&#39;m quite possibly overlooking a lot of details...</div>
<div><br>There may be other benefits to doing this kind of escape-analysis, aside from making short-lived allocations cheaper (which are indeed already quite cheap)... </div>
<div>If you can associate a bunch of allocations with a point in the stack, even if it&#39;s very low in the stack (and thus long-lived), there&#39;s a lot less work that the GC needs to do to track all the other allocations (in the global heap), since there&#39;s just fewer of them.</div>

<div> </div>
<div>Also, each stack is associated with a specific thread, so it sort of brings you half-way to per-thread GC, in the sense that all the stack-based resource management is per-thread.</div></div>
<div></div><br>-- <br>Sebastian Sylvan<br>+44(0)7857-300802<br>UIN: 44640862<br>