On Fri, Aug 24, 2012 at 8:31 PM, Jonathan Pryor <jonpr...@vt.edu> wrote:
> > 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? > > Java. :-) > > 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. > > 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: > > http://stackoverflow.com/questions/473685 > http://stackoverflow.com/a/503714/83444 > > 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. > Thanks for that detailed description. 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. However, at least I now understand why this idosyancracy exists. Thanks very much!
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list