• Post Reply Bookmark Topic Watch Topic
  • New Topic

When is an object not referenced? How does GC collect?  RSS feed

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,

I was just wondering when an object is really no longer referenced in the dynamic memory.

So from my understanding:

the right hand side is creating an object of type House and h1 is a reference to that object in memory.
So say I stop using the h1 object later in my program, not invoking methods etc. when will the garbage collector discard of it?

Commonly, how do objects stop getting pointed at by the program in memory?
Or does the GC determine which one has not been mentioned/called in the program the longest and discards of it, making space in the heap... even though it may need to be created again later in the program? Causing performance problems in certain program applications.

Thanks in advance for any response
 
Ranch Hand
Posts: 614
9
BSD Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In simple sentence, the object will be eligible for garbage collection when it has no reference attached to it.
In other words when no one can access the object in the program.
It can happen in many ways. I will put 2 scenarios for your understanding.
1.

Thus the House object which was created in heap now has no reference attached to it.
2.Let us assume this statement is inside an if condition.

So when the execution of the block inside if condition is done, there is no one in the program who can access the created object. So it will be eligible for garbage collection.

Now can you decide few other scenarios when objects will be eligible for garbage collection?
 
Marshal
Posts: 56610
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You cannot create the same object twice. If you maintain a reference to that object, it will be maintained in memory and not GC‑ed. Remember that putting a reference into a List or similar will preserve it.

If you can find the reference back in your code, then the object is not eligible for GC.
 
Ranch Hand
Posts: 368
3
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An object is alive on heap until its reference variable is alive
There are 3 ways to kill object
1-assigning a new object to the reference variable
2-by explicitly assigning reference variable to null
3-by making reference variable go out of scope permanently
 
Tody Dimon
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you all so much for the helpful responses

I think I get it now, I did not even think about scope!

I've just been hearing about how Garbage Collection can clear out so many objects from the heap and can be very frequent...

But in the simple programs I'm writing at the moment, there probably is not much GC going on

If anyone is stilling hanging, could you give me some examples of how and why Garbage Collection can be such a big problem in some critical applications?


 
Campbell Ritchie
Marshal
Posts: 56610
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sachin Tripathi wrote:An object is alive on heap until its reference variable is alive
There are 3 ways to kill object
1-assigning a new object to the reference variable
2-by explicitly assigning reference variable to null
3-by making reference variable go out of scope permanently
None of those will reliably cause an object to be GC‑ed. You can usually do more harm than good by assigning something to null.
 
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do not ever assign null to a variable in an effort to try and micro-manage GC. Just let variables and objects go out of scope naturally.
 
Ranch Hand
Posts: 789
C++ Linux Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tody Dimon wrote:
give me some examples of how and why Garbage Collection can be such a big problem in some critical applications?

GC is guaranteed to run on its own before you get OutOfMemoryException so if you ever get that, you need a re-write or more memory or you need an unbroken JVM
 
Sachin Tripathi
Ranch Hand
Posts: 368
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As op has asked for ways by which an object can
become non reachable.So all those ways suggested by me are only meant for that purpose


Will you elaborate the reason why reference variable shouldn't be assigned to null
 
Campbell Ritchie
Marshal
Posts: 56610
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because nulls are very error‑prone. If you let a null into your program there is a risk of it reappearing 1000 lines and 50 classes away and causing an Exception.

There are a few places where it is necessary to assign to null, for example in the pop() method of a Stack.
 
Tody Dimon
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting!

So why does the JVM assign a new memory address in the heap for the object variable, when you assign a different (new) object?

I am guessing it is different from when you can overwrite values in variables, that are pushed onto the stack.

Is this because the new object may be a larger size and may not fit into that particular address anymore, or is it just random?

Thanks all : )
 
Campbell Ritchie
Marshal
Posts: 56610
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tody Dimon wrote: . . .
So why does the JVM assign a new memory address in the heap for the object variable, when you assign a different (new) object?
. . .
Whenever you create a new object, that is completely distinct from all other pre‑existing objects and needs to have its own memory space. You can assign that memory location to as many variables as you like (or as few, including 0). It has nothing to do with the size of the object. It is not random either, but you would have to go through the JVM's code to try and work out the algorithm. Also, it is one of those things you don't actually need to know.
I think you are confused about “overwrit[ing] variables”. If a variable is a field, it lives inside the object, usually on the heap. Only local variables are to be found on the stack (beware oversimplification).
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!