Garbage collection objects

[m ali]

Hi All,

Everytime I am confusing with the questions like "How many objects eligible for garbage collection when the given code completes?". Please anyone explain me some points or tips to get out of from this type of questions.

Thanks in Advance.

[fred rosenberger]

First, you have to be sure you understand the difference between an object and a reference to the object.

MyClass myRef = new MyClass();

this creates an object somewhere in the heap. it also creates a reference variable called 'myRef' that effectivly points to the spot in the heap where the object is.

What I do when I need to figure these out is draw a picture. The right side is my heap - i draw circles and label them with the type and relevant data, such as the string literal used to intialize it.

on the left, i list the references. I then draw arrow to show where each ref is pointing to.

so, if i the line

MyClass ref2 = myRef;

i'm going to have two things on the left, each with an arrow pointing to the single object on the right.

i then go through the code line by line, drawing and erasing arrows as needed. you can then see when an object has no arrows pointing to it, thus making it eligible for garbage collection.

[Arad Chear]

 
public static void main(String [] args) { 
 
    String s=new String("EW");
    String s2=new String("AS");
     go(s,s2);
  
}
static void go(String s1,String s2){
    s1=null;
    s2=null;
}
 
  

is s,s2 is eligible since its pass by reference ?

[Chandra Bhatt]

Nice explanation Fred,

But one question remains, I am not getting answer of that clearly is:

All the objects created inside a method are eligible for garbage collection
once method completes. If method passes reference to any object created inside the method to the outside world is an exception to this fact.

So how to determine, whether an object is eligible for GC or not.
Is your (you described in just previous post) method is applicable in
all the scenario.



Please clarify my doubt!!!


Regards,
cmbhatt

[Chandra Bhatt]

Eisa says,
public static void main(String [] args) {

String s=new String("EW");
String s2=new String("AS");
go(s,s2);

}
static void go(String s1,String s2){
s1=null;
s2=null;
}
is s,s2 is eligible since its pass by reference ?

No Eisa, You missed the vital part of concept. What is sent to the method is copy of the reference. In your example add one more line to understand the fact:

public static void main(String [] args) { 
     
        String s=new String("EW");
        String s2=new String("AS");
        go(s,s2);
        System.out.println(s); //prints EW
        System.out.println(s2);  //prints AS
      
    }

Did you get anything from the output. Setting s and s2 to null has local
impact inside the method go() only.

Note: If using that reference variable, you do internal modification on the
object, it will have global impact, because object is same. But if the called method make reference variable "null", it means it is losing the reference of the object on the heap. Calling method reference variable wont have any effect of that. It's reference variable still points to the object on the heap.

Got it?


cmbhatt
[ April 23, 2007: Message edited by: Chandra Bhatt ]

[Arad Chear]

yes got it ,

Chandra about your question ,
all Objects will eligible for GC unless Object returned

thats what K&B say

[fred rosenberger]

I don't have the book here in front of me, but I think you are missing a subtle point.

In Java, you do not pass objects. You can't. Java doesn't work that way.

What you are passing is the reference - or more specifically, a copy of the reference.

It's like passing a copy of a business card, or an address label that tells you where my house is.

so, let's go through this code (note: i'm changing it from Strings to MyClass so we don't have to worry about the string pool):

public static void main(String [] args) {
    MyClass mine1=new MyClass("EW");               //1
    MyClass mine2=new MyClass("AS");               //2
    go(mine1,mine2);                               //3
    //possibly more code...
}
static void go(MyClass s1,MyClass s2){             //4
   s1=null;                                        //5     
   s2=null;                                        //6
}

after line 1 executes, we have a MyClass object that lives in the heap. We also have a reference, mine1, that points to the object. it's like a notecard with my home address, and the object is my house. I carry around the notecard so i can find my house, I don't carry the actual house.

after line 2, we have a SECOND MyClass object on the heap, and second reference that points to this object.

when we call line 3, we make copies of the mine1 and mine2 reference - think of it as handing the method a photocopy of my home address.

line 4 takes these values/photocopies, and assigns them to the go method's s1 and s2.

at this point, we have mine1 and s1 BOTH pointing to the same object. We have two notecards with my home address on them. The same for mine2 and s2. Within the method we can't really access mine1 or mine2, but the references are still valid.

when on line 5 you set s1 to null, you erase the address off that card. That does not change the actual object, nor does it change mine1. mine1 still holds a valid reference to the object.

Line 6 does the same for the other object/references. s2 no longer points to the object, but mine2 does.

we then return from the method. Note that no object became elligible for GC within the go() method.

it is wrong to talk about "s1 being elligible" since s1 is a reference, not an actual object. if s1 currently refers to an object, then that object is by definition not elligible. if s1 does not currently refer to an object... there is no object to be talking about.

[Chandra Bhatt]

Wow Fred,

What a simple way to grasp the things, "passing photocopies of reference
variables to the method", setting them to null in the called method means "erasing address on the its own cards".

Fabulous!!!



cmbhatt

[m ali]

Hi Guys,

Thanks to one and all, for such nice explanations.

[Meena R. Krishnan]

Thanks Fred! Very nice!