As Bill surmised, the compiler reserves the right to free local variables when it can prove it will not be used again.
On Thu, Oct 1, 2015 at 8:06 AM Yichao Yu <[email protected]> wrote: > On Thu, Oct 1, 2015 at 6:33 AM, Bill Hart <[email protected]> > wrote: > > Actually, perhaps a slightly better question would be: how is Julia's gc > > implemented? When the gc is called (which I understand could happen at > any > > time), does it search the stack for valid references to objects? > > > > If so, then I think I can answer my own question. The LLVM optimiser > could > > in theory reuse the space in which a pointer lives, for something else, > so > > long as it can prove the value is not used again. That's something > outside > > of Julia's control, and so there's no guarantee the object associated > with a > > variable will live to the end of scope. > > > > Bill. > > The GC keeps all local variables alive and I think we'll probably keep > this valid for finalizers. > > This is independent about implementation details. > > > > > > > On Thursday, 1 October 2015 12:23:43 UTC+2, Bill Hart wrote: > >> > >> Is there any relationship between Julia's lexical scoping and garbage > >> collection? > >> > >> What I mean is: if I have a function inside which is a variable which is > >> not used from some point onwards in the function, does the object live > on > >> until the end of scope or is it possible that it may be gc'd before the > end > >> of the scope of that variable? > >> > >> Obviously I'm asking because we want to keep an unsafe pointer to the > >> internals of some C object which is only used inside that function, but > >> possibly after the last use of the Julia managed object. > >> > >> Shorter version of question: how does Julia decide when it is safe to > >> clean up a an object bound to a variable that is still in lexical scope? > >> > >> (I realise of course that if the variable in question is assigned some > >> other value there is no longer a valid reference to the object and all > bets > >> are off.) > >> > >> Bill. >
