Life cycle of local Java objects created during a method call

Question

In a method call, if I create an object during that call. When are those objects garbage collected?

Are they placed on the heap and then garbage collected along w

Answer 1

Objects created within method scope are eligible for garbage collection when the method is closed - unless that reference is passed back as the return value. In that case, the caller may or may not hang onto that reference and prevent it from being gc'd.

Since the garbage collector runs on its own thread according to its own lights, you don't necessarily know when an object is cleaned up, or whether or not objects allocated elsewhere are eligible as well.

Answer 2

This is not so easy - in the very end every object is created in some method.

The VM / compiler needs to make escape path analysis to detect if a reference of this object in some way can escape - imagine calling newObject.toString(). You and me know (hope) that this will do no harm and the object is still not referenced, as it will not link itself to a global variable. But the VM dows not.

While a modern VM will do such analysis and treat real short lived objects special in garbage collection, from a "high level" point of view they are just objects. Everything else is sophisticated low level optimization.

And anyway, as duffymo says - when exactly this objects are freed is uncertain.

Answer 3

The fact that the execution of the method has ended and now the object is out of scope is irrelevant.
Garbage collection is an implicit operation of the runtime system running in a separate thread in parallel with your code, implementing a specific garbage collection algorithm.
The garbage collection thread runs at unpredictable times-but very often, every second or so according to java docs and when the memory is almost run out, evaluating which objects are eligible to be garbage collected i.e. there are no references to them from root pointers e.g. static variables.
So every object accessible by a root pointer is marked and then recursively the objects referenced by these objects etc.
This can mean scanning the entire process space. Once done, all the objects not "marked" from previous scan go to the free list (are GC'd).
This is a heavy operation as you can see.

The execution of that method has completed.

So the fact that you are out of the scope of a method you called because it has completed, is irrelevant. It does not mean that the runtime knows at that point that the object is done (since GC is run in parallel).
It is not like in C++ that in the end of the method the programmer would call delete on the object since it is not needed. No "delete" is automatically called at the end of the method in Java.
The GC thread will eventually realize that there are no more references to the object allocated on the heap by the method and CG it.
You can call the GC at any point if you want by:

System.gc();

But the GC will run sooner or later anyway.
One thing to note is as long as there is a reference to a method by a root pointer it can not be GC's.
So if in your method you create via new an object on the heap and you store the reference in a container that is static or return it to the caller, the object outlives the method.