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?
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)1.
Objects are another matter. Objects (including arrays) are normally2 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With