GC (enthuware question)

[Przemek Malirz]

Hi All,
This is the question from enthuware:

After which line will the object passed to the method getObject() be eligible for garbage collection?

public void getObject(Object a)
{
   Object c, b = new Object(); //1
   //do something with a
   c = b; //2
   a = c;//3
   b = a = null; //4
   c  = null;
}

Answers: //1, //2, //3, //4, None of these
And the correct answer is: None of these
Enthuware Explenation:
"All the assignment operations are just adding the confusion. The point is that the objects passed to a method can never be garbage collected in that method. The reason is simple - such objects are created outside the method and so there are references pointing to these objects outside the method. The references inside the methods are a mere copy of the outside references. Making these null, will not affect the outside references."

I answered //3, because I thought that the invocation of method getObject may look like this:

getObject(new Object())

so, am I wrong ?

[Siri Naray]

Before reading the enthuware explanation I answered 3. The reasoning for "None of the above" makes sense to me but i dont see this explained anywhere even when I googled. When an Object reference is returned from a method to the calling method then the Object is not eligible for Garbge collection. but when an object ref is passed as an argument, no where it says it cannot be garbage collected.
Can anyone throw some light on this??

[Nabila Mohammad]

Originally posted by Przemek Malirz:

After which line will the object passed to the method getObject() be eligible for garbage collection?

public void getObject(Object a)
{
   Object c, b = new Object(); //1
   //do something with a
   c = b; //2
   a = c;//3
   b = a = null; //4
   c  = null;
}

Answers: //1, //2, //3, //4, None of these

My answer before looking at the correct answer was none of thesee.
I don't know how far i am right but the way i saw it was ,
that all obejects ie. all references are pointing to only one object -b.
That means a,b,c are all pointing to one object.

b = a = null; //4
After line 4 , a and b are null , however, c is still pointing to the same object and therfore still not eligible for GC.

c = null;
After this line, all the three objects are null and there for this object is elegible for GC.
This line is however not mentioned in the answer, so i thought the answer would be None of these.

[Ankit Garg]

Hmmm...tricky question....Looks like the enthuware mock exam is good. Can anyone tell me whether whizlabs is better or enthuware???

[Przemek Malirz]

IMHO:
This answer (None of these) is good only when invocation of getObject() method looks like:

Object obj = new Object();
getObject(obj);
// 1

then when we ahieve line // 1 there still will be reference "obj" to an Object.

But, when we invoke this method in other way:

getObject(new Object());

then the only reference to newly created object is a local (method) variable/parameter "a". In this case correct answer should be // 3.

What do You think about it ?

[ankit kumar]

public void getObject(Object a){
Object c, b = new Object(); //1
//do something with a
c = b; //2
a = c;//3
b = a = null; //4
c = null;}

In this we are not constructing the object a .we are only getting the refrence of the object from ooutside the function .it is not the local object for this function . in this code there is no possibility that garbage collector will call the object a in this function.

[Przemek Malirz]

Again.

The question is: "After which line will the object passed to the method getObject() be eligible for garbage collection?"

So, why do you assume that we are geting the existing refrence of the object from outside the function. Why do you think that there exist any reference to this Object outside the method ?

To the method is passing an Object !, so this function might be called like this:

getObject(new Object());

And this is a big difference.
Enthuware question doesn't tell that outside getObject method exist reference variable to this Object, and that this variable is passed to this method.

Enthuware explenation is incorrect:
"...The point is that the objects passed to a method can never be garbage collected in that method. The reason is simple - such objects are created outside the method and so there are references pointing to these objects outside the method..."
Wrong !!! There might be no reference at all !!!

getObject(new Object());

- we have object created outside the method and no referencing variables pointing on them besides local method variable (parametr "a") !!!

?

[Ankit Garg]

Przemek Malirz in any case the object will not be eligible for garbage collection in the method getObject. if you pass it (new Object()) then the object will be eligible for garbage collection when the call returns and the statement of the call executes completely..

so

getObject(new Object());
//now the object is eligible for garbage collection....

[Henry Wong]

And this is a big difference.
Enthuware question doesn't tell that outside getObject method exist reference variable to this Object, and that this variable is passed to this method.

During the test are you allowed to question the question or must you answer it? During the test, when you are facing an unknown, and hence, can't be sure of two possible answers, should you assume the common case? Or should you assume the fringe case? Or should you just not make an assumption and not answer the question?

Enthuware explenation is incorrect:
"...The point is that the objects passed to a method can never be garbage collected in that method. The reason is simple - such objects are created outside the method and so there are references pointing to these objects outside the method..."
Wrong !!! There might be no reference at all !!!

Actually, you don't know if Enthuware is incorrect here. The registers may be saved as part of the method call, and since the last thing the registers were doing was building the stackframe, the object may still be accessable -- until the method call is done, and the registers are cleaned up.

Regardless, back to the first point -- isn't it better to assume the more common case. And answer accordingly? Isn't the goal to pass the test?


Having said that, this is an interesting discussion, and I would be interested to see where it goes....

Henry

[Przemek Malirz]

Thanks for your answer.

So why below code produce an output:
1
getObject.A
Huge.finalize
getObject.B
2

public class Main {
 
    public static void main(String[] args) {
        System.out.println("1");
        getObject(new Huge()); 
        System.out.println("2");
        
    }
    
    public static void getObject(Object a){
        a = null;
        System.out.println("getObject.A");
        System.gc();
        for(int i = 0;i < 20000;i++);
        System.out.println("getObject.B");
    }
}
 
class Huge {
        protected void finalize() throws Throwable {
            System.out.println("Huge.finalize");
        }        
}

[Puneet Nahata]

public void getObject(Object a)
{
Object c, b = new Object(); //1
//do something with a
c = b; //2
a = c;//3
b = a = null; //4
c = null;
while(true){}
}

and the call to this method is: getObject(new Object())

Since this method call would never return, that means Object a will never be eligible for garbage collection. Am i right???
Or is it eligible for garbage collection at line 3???

Please clarify my doubt.

[Paul Anilprem]

Originally posted by Przemek Malirz:
Thanks for your answer.

So why below code produce an output:
1
getObject.A
Huge.finalize
getObject.B
2

Hello,
The output proves nothing. GC thread is different from current thread. Their outputs can be interspersed. When I ran the program, I got -

1
getObject.A
getObject.B
2
Huge.finalize
 

Try this code -

  public class Main {
public static void main(String[] args) {
System.out.println("1 Id = "+Thread.currentThread().getId());
getObject(new Huge()); 
System.out.println("2 Id = "+Thread.currentThread().getId());
 
}
 
public static void getObject(Object a)
{
a = null;
System.out.println("getObject.A Id = "+Thread.currentThread().getId());
System.gc();
for(int i = 0;i < 20000;i++);
System.out.println("getObject.B Id = "+Thread.currentThread().getId());
}
 
}
 
class Huge {
protected void finalize() throws Throwable {
System.out.println("Huge.finalize Id = "+Thread.currentThread().getId());
} 
}

[Puneet Nahata]

So the conclusion is that if we pass an Object reference to a method then that object will never be eligible for garbage collection inside that mehtod.

But if we pass an actual object, then that object can be eligible for garbage collection inside that method.

Am i right??

[Przemek Malirz]

IMHO: Yes !

[Przemek Malirz]

And this is what I try to prove.

"if we pass an Object reference to a method" an enthuware question is correct, and "if we pass an actual object" the question is incorrect.

[Paul Anilprem]

Originally posted by Przemek Malirz:
And this is what I try to prove.

"if we pass an Object reference to a method" an enthuware question is correct, and "if we pass an actual object" the question is incorrect.

I think you may be right. Let us see the following java code and the generated bytecode -

public class TestClass 
{
   public int m1(Object obj)
   {
return 1;
   }
 
   public void m2(String[] args)
   {
m1(new Object());
   }
}
 
public TestClass();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>" :(  )V
   4:   return
 
public int m1(java.lang.Object);
  Code:
   0:   iconst_1
   1:   ireturn
 
public void m2(java.lang.String[]);
  Code:
   0:   aload_0
   1:   new     #2; //class java/lang/Object
   4:   dup
   5:   invokespecial   #1; //Method java/lang/Object."<init>" :(  )V
   8:   invokevirtual   #3; //Method m1 :(  Ljava/lang/Object :wink: I
   11:  pop
   12:  return
}

If you analyze bytecode for m2(), you will observe -
0: load 'this' reference on stack
1: create a new object of class Object and put the reference on stack (let's call it 'new')
4: duplicate the reference on top of stack (which is actually the reference to new object i.e. duplicate 'new')
5: call constructor on the new object (the dup reference is thereby removed and the 'new' is now on top of the stack)
8: create a new stack for calling m1, call m1 on 'this' and pass 'new' ('this' and 'new' are now popped, reference to the stack frame of m1 remains on the current stack)
11: pop the reference of the stack frame of call to m1.
12: return

Number 8: is important. It seems that the references this and new are popped from the current stack frame and there is no reference to the new object on the current stack frame anymore.


Contrast the above with the java code and byte code for another similar program -

public class TestClass2 
{
   public int m1(Object obj)
   {
return 1;
   }
 
   public void m2(String[] args)
   {
Object obj = new Object();
m1(obj);
   }
}
 

 
public TestClass2();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>" :(  )V
   4:   return
 
public int m1(java.lang.Object);
  Code:
   0:   iconst_1
   1:   ireturn
 
public void m2(java.lang.String[]);
  Code:
   0:   new     #2; //class java/lang/Object
   3:   dup
   4:   invokespecial   #1; //Method java/lang/Object."<init>" :(  )V
   [B]7:   astore_2[/B]
   8:   aload_0
   9:   aload_2
   10:  invokevirtual   #3; //Method m1 :(  Ljava/lang/Object :wink: I
   13:  pop
   14:  return
 
}

Here, at 7: the reference to new is stored in the local variable table for the method m2.

I am not 100% sure if I am reading the bytecode right. Still investigating...

[chander shivdasani]

The explanation is truly justified. You never know how many references are there to the object that is passed to the method. In the method it looks that we are removing only one reference, but there can be other references in the block that called this method.

[Przemek Malirz]

I don't think so. The explanation try to tell us that the object passed to the method getObject can never be garbage collected, and i think that's not true!

"...The point is that the objects passed to a method can never be garbage collected in that method. The reason is simple - such objects are created outside the method and so there are references pointing to these objects outside the method..."

[Ankit Garg]

Hmmm...Interesting....

[Przemek Malirz]

I still think that this sample output

1
getObject.A
Huge.finalize
getObject.B
2

show us that an object inside the method was garbage collected between calls
getObject.A and getObject.B.

[Paul Somnath]

public class Main {
 
    public static void main(String[] args) {
        System.out.println("1");
        getObject(new Huge()); 
        System.out.println("2");
        
    }
    
    public static void getObject(Object a){
        a = null;
        System.out.println("getObject.A");
        System.gc();
        for(int i = 0;i < 20000;i++);
        System.out.println("getObject.B");
    }
}
 
class Huge {
        protected void finalize() throws Throwable {
            System.out.println("Huge.finalize");
        }        
}

Hi ,
In your call to the Garbage Collector, you are just making a request to the JVM to garbage collect, when the JVM does it you dont know(it may do as soon as it executes the System.gc() or it may delay it till the end of the program, so in my opinion this code cannot predict the output from this program. I also think that there are some assumptions to be made for this question to be answered. And the safest assumption would be to assume that the object passed MAY have references. You dont know how this method is called so you have to make this assumption. I fully agree with Henry Wong in this case. There could be more scenarios attatched to this problem, so the safest assumption to make is that the object MAY have references outside the method so its NOT GUARANTEED that the object would be garbage collected inside the method.