Reputation: 21865
Consider the following code :
class MyObject {...}
class MyClass
{
public void executeSomeFunc()
{
// do something
}
public static void main(String args[])
{
int x = 1;
x++; // where does GC starts on "x" ? after that line ?
int y = 2; // or after that ? or somewhere else
y++;
executeSomeFunc(); // declared earlier
// more code
// much more
MyObject myObj = new MyObject();
// more code
}
}
I'm interested on the location where GC starts to work on x
.
Where is it ? after x++;
? or at another point in the code ?
EDIT :
What about myObj
?
Much appreciated
Upvotes: 0
Views: 105
Reputation: 1902
when does the GC run and when does an object become eligible for GC are two very very different questions. Just because an object becomes eligible for GC doesn't mean that the GC will run immediately to recover it.
In your example x and y are primitives and they are not GC candidates. GC applies primarily to object heaps and not stack based data. As Sotirios mentioned above, believing x is a gc candidate is wrong. myObj will be a GC candidate once the scope in which it is defined finishes AND presuming that myObj is not leaked within that scope.
Now about when does the GC run to reclaim the myObj? answer to that is, no one knows. GC implementations are primarily daemon thread based (sometimes in app threads too) and they scan the heap for garbage. Only thing that is guaranteed to occur is that when app tries to allocate some memory to an object being created or restructured, and JVM denies it because of unavailability (this is called as allocation failure event in GC parlance) then GC threads are fired to reclaim any memory if available. They first run on eden space to reclaim any young gen memory, orphans are cleaned and others are moved to survivor space. them the GC is run on tenured space. same things happens there too. once its cleared, the survivor objects are move dot tenured and the GC sleeps. If no memory can be reclaimed you get an OutOfMemory exception. If memory is recovered you dont feel a thing and everything works as usual.
Upvotes: 0
Reputation: 279930
The answer is never. x
is a local variable of a primitive type. Its value is allocated on the stack. Once the stack frame is popped (ex. method returns), the memory is de-allocated immediately, no garbage collection involved for it.
As for the object referenced by myObj
, if no reference chain exists to it after the method returns, it will be eligible for garbage collection.
Upvotes: 3
Reputation: 14164
GC becomes active when local references go out of scope/ disappear from the stack frame. That would typically be when the method returns.
GC specification is to mark objects as "reachable" starting from active threads & stack frames. It traverses & marks all reachable objects, and then collects unreachable ones. Parallel and concurrent collectors refine exactly how & when this happens, but that's the basic approach.
Upvotes: 0
Reputation: 92
Garbage collector collects an object when it's not referenced. But GC collects objects. x and y are primitive types here. So, they are going to be there till main ends running.
For myObject, GC is going to do nothing. If you assign null to it at some point, then the object is going to be collected.
Again, primitive types are not going to be collected.
Upvotes: 0