What destroys the local variable in java?

Question

I suspect that the method-local variables live only as the method is being executed. Also, GC is triggered when Eden or Long-generation blocks are overflowed (minor/major GC) etc... So, what if at the end of the method body Eden is not overflowed, so there is no need to trigger GC. In spite of not triggering major/minor GC we shall destroy all local variable. How is it done?

Stephen C · Answer 1 · 2019-09-15T13:10:35.373

Method local variables (or just "local variables" as they are normally called) are allocated on each thread's stack. The variables themselves are not subject to garbage collection. They are reclaimed automatically when the method call terminates (normally or abnormally)¹.

Objects are another matter. Objects (including arrays) are normally² allocated on the heap, and they are subject to garbage collection.

So what about an object (or array) that is allocated by a method and assigned to local variable?

First of all, the local variable holds a reference to the object. The object is stored in the heap (see above).

When the garbage collector runs (and you generally don't know when that will be!) it will check any existing local variables for method calls that are still in progress. It the variables contain references to objects, those objects are added to the list of objects to be kept ... and they are checked for references to other objects, and so on.

So, in summary, local variables are destroyed automatically when the method call ends, but the objects that those variables refer to will continue to exist until the GC (eventually) figures out that they are unreachable.

^{1 - We need to consider local variables that are accessed from an inner class or lambda that is declared within the scope of the variable. The class of lambda instance may passed somewhere so that it can be used after the method returns. In this case, the you would think that the local variable needs to live after method has returned. In reality, what happens is that the local variable is copied to a synthetic field in the object that represents the inner class or lambda instance. The class / lambda then uses the value in the field. The original variable does disappear when its method terminates.}

^{2 - Recent Hotspot JIT compilers have an optional optimization called "escape analysis" that is used to find cases where objects created by a method call can be allocated on the thread's stack. This is not enabled by default. If an object is allocated on the stack, then it will be reclaimed when the method call ends. The GC is not involved.}

^{3 - You said: "GC is triggered when Eden or Long-generation blocks are overflowed (minor/major GC) etc...". This is not necessarily so. Some of the low-pause collectors are triggered before the respective spaces fill up. However, this doesn't alter any of the above.}

Jon Kiparsky · Accepted Answer · 2018-05-21T17:32:00.970

9

The garbage collector - the Reaper, as it's sometimes known - runs on its own schedule, and collects objects which are out of reference. The local variables, of course, cannot be referenced after the method exits, because they are out of scope, so to your program they are dead*, but they still exist on the heap until the GC runs.

Under normal circumstances (and most abnormal ones) you do not need to tell the Reaper when to do its work. It will come, silently, when it is needed, and carry away those things which are no longer needed. This is one of the major advantages of working in a high-level language: it's safe to assume that you never need to think about things like managing deallocation of dead objects. You can just toss them over your shoulder and know that they will never bother you. I suppose there are some high-performance, high-demand applications that need to fiddle with the GC, but that's an optimization which should always be presumed premature unless you have really good evidence to the contrary.

*except, of course, for local variables which are returned to the calling function, which may become local variables in that scope and gain a little more lease on life. In general, the rule is: if some part of your code still cares about the variable, it will not be garbage collected, and if no part of your program cares about it, then you don't need to think about it.

edited May 21 '18 at 17:32

answered Dec 21 '14 at 06:30

Jon Kiparsky

7,499
2
23
38

Looks like the truth. – St.Antario Dec 21 '14 at 06:50
2

It is never known as "the Reaper" in Java. Or at least, not by any credible / creditable sources. – Stephen C Dec 21 '14 at 07:14
3

@StephenC I don't think that this's so important. At least, I understood what Jon was trying to say. – St.Antario Dec 21 '14 at 07:17
@StephenC Do you have a source for that assertion? :) – Jon Kiparsky Dec 21 '14 at 07:18
1

Yes. Me. I'm the source. Do you have any counter-examples? (Apart from yourself.) – Stephen C Dec 21 '14 at 11:46
1

I agree with Stephen, I have never heard anyone call it the reaper before. – Mark Rotteveel Dec 21 '14 at 14:59
@StephenC Since we're talking about existence, I'm a better source for "sometimes" than you are for "never" - if I ever refer to it that way (and I do) , then "sometimes" is established. :) (I don't actually know why this chaps you so...) – Jon Kiparsky Dec 21 '14 at 15:06
@JonKiparsky - OK then, since you claim to be a source for "sometimes", provide us with an example where a creditable Java source / expert uses "reaper" to refer to the Java GC. Why it "chaps" me so is that you are implicitly telling people it is OK to use weird terminology, and that is bad. – Stephen C Dec 23 '14 at 11:05
2

"The local variables, of course, cannot be referenced after the method exits [...]" what if they're returned by the method in question? – runeks May 21 '18 at 08:27
FWIW: I just did some (unscientific) searches for "java gc reaper" and "java reaper". I found no hits (apart from this Q&A) that seriously referred to the GC as the reaper. There were lots of references to reaper threads that periodically cleaned out data structures, closed connections, and so on. I did see one comment that referred to "the grim reaper" ... but that was clearly intended as a joke. – Stephen C Sep 15 '19 at 05:24
"*"The local variables, of course, cannot be referenced after the method exits [...]"* what if they're returned by the method in question?" - Variables are not returned. The values that *were* in the variables may be returned. Now it is also possible to create and return an anonymous class or a lambda that refers to a local variable. Or that *appears to* do that. In fact, what actually happens is that the value in the local variable is copied to another variable in the object that represents the anonymous class instance or the lambda. – Stephen C Sep 15 '19 at 11:28
(continued) The original local variable *does* disappear when the method that declared it returns. This works because of the restriction that an anomous class or lambda can only refer to an outer local variable if the variable is *effectively final*. Since it is effectively final, it is not possible to tell that the variable (i.e. the memory cell) is a different one to the original variable. – Stephen C Sep 15 '19 at 11:29

score 1 · Answer 3 · answered Dec 21 '14 at 06:28

1

Java virtual machine uses linear stack to manage (store/access) local variables and method parameters, so it's just setting the stack pointer to the point where none of locals and parameters were declared and moves on. It's no need to use GC

answered Dec 21 '14 at 06:28

rostamn739

323
3
8

It's a bit not clear. How does GC distinguish between local/non-local variables stored into Eden? – St.Antario Dec 21 '14 at 06:52
@St.Antario The GC doesn't care about local or non-local. It cares about active references. If a variable has no active references, then nothing can refer to it, so it can be reclaimed. When a method exits, any local variables lose their local references, so unless you've passed them to some other object which is hanging on to them, they're going to go to the great bucket in the sky. – Jon Kiparsky Dec 21 '14 at 06:56
@JonKiparsky So, we can reuse memory which is not reffered by any active reference. In the case of local variables, after the function body's completed we can put a new object to the place where the local variable was stored, right? – St.Antario Dec 21 '14 at 07:13
1

@St.Antario Well, the point is that in Java you never need to think about where you're putting objects. The machine allocates memory, and the machine reclaims memory, and you may safely assume that as long as you don't try to allocate more memory than the VM has, it's going to find a way to make it all work. Again, that's one of the benefits of using a higher-level language. You don't have to think about the state of the heap. – Jon Kiparsky Dec 21 '14 at 07:17
@St.Antario But yes, you're correct: when a function's body completes, it will not be long before any memory allocated within that function will be available, as long as that function has not passed a reference to the object in that location to something that's holding on to it. – Jon Kiparsky Dec 21 '14 at 07:20

What destroys the local variable in java?

3 Answers3

Linked