On Fri, Aug 24, 2012 at 8:31 PM, Jonathan Pryor <span dir="ltr"><<a href="mailto:jonpryor@vt.edu" target="_blank">jonpryor@vt.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">> I'm sorry for my naivety. Why does allowing unused function arguments to be collected before a function returns have such important effects on memory usage?</div><div class="im">
<br>
</div>Java. :-)<br>
<br>
The context is the JVM, and "large" methods. Many JVM implementations used to do as you suggested, and wouldn't collect a variable until the method referencing the variable returned. This even applied to local variables! Instead of having "precise lifetime" semantics (as determined by the instruction pointer), it only cared about stack frames.<br>


<br>
The result of this behavior is that developers would write "huge" methods which allocated "lots" of objects, all of which would be considered "live" even when a local was no longer being used. Thus came a body of guidelines that you should null out instance/local variables so that the GC could actually collect intra-method garbage:<br>


<br>
        <a href="http://stackoverflow.com/questions/473685" target="_blank">http://stackoverflow.com/questions/473685</a><br>
        <a href="http://stackoverflow.com/a/503714/83444" target="_blank">http://stackoverflow.com/a/503714/83444</a><br>
<br>
Needing to null out a local variable is, of course, insane -- "why can't the GC figure this out!" -- so .NET (and modern JVMs!) now precisely track which variables are in-scope and out-of-scope, and will allow collection of any-and-all out-of-scope variables even within the method.<br>

</blockquote><div><br></div><div>Thanks for that detailed description.</div><div><br></div><div>I don't still don't see why function arguments are handled as aggressively as local variables. One could argue that the contract of a function call implies that the arguments are "referenced" by the caller until after the call is completed... For example, expect that in "new Foo().Bar();", Foo is not eligible for collection until after Bar returns. </div>

<div><br></div><div>However, at least I now understand why this idosyancracy exists. Thanks very much! </div></div>