File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Object eligible for GC? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Object eligible for GC?" Watch "Object eligible for GC?" New topic
Author

Object eligible for GC?

Paul Yule
Ranch Hand

Joined: May 12, 2008
Posts: 229
This is from the 1.4 practice exam from Mark

Given the following code, how many objects will be eligible for garbage collection on the line with the comment //here

The Correct Answer is
1) 0

A reference passed into a method is passed as if it were a copy of a pointer pointer rather than the actual object. Thus if that reference is assigned to a null it makes no difference to any other copy of that pointer. Thus the code within the method findOut makes no difference to any other references. Although reference z is assigned to null reference y still points to the object so no objects are eligible for garbage collection.

Isn't z available for GC? When the z Integer references y, y doesn't gain a reference to z does it? So z should be eligible for garbage collection. Perhaps there was suppose to be a line for "y=z"?
[ September 12, 2008: Message edited by: Paul Yule ]
Rusty Shackleford
Ranch Hand

Joined: Jan 03, 2006
Posts: 490
It doesn't have any reference, but it is a method parameter which normally lasts until the end of the method, but on the other hand it is set to null, which should automatically make it eligible for GC.

I think the given answer isn't correct.

This might help: http://www.janeg.ca/scjp/gc/eligible.html
[ September 12, 2008: Message edited by: Rusty Shackleford ]

"Computer science is no more about computers than astronomy is about telescopes" - Edsger Dijkstra
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36486
    
  16
I think Rusty is correct.

  • The reference z doesn't point to anything, so we can ignore it.
  • The reference y pointed to an Integer(99).
  • The method calls findOut(x) and findOut(y) are red herrings. Pass-by-value, remember. The fact that the local variable in the findOut method is asigned to null doesn't make any difference to the original reference.
  • The reference x pointed to an Integer(10).
  • So when you get to wherever it is, two Integers value 10 and 99 are available for GC.

  • Rusty: am I anywhere near the right answer?
    Abhinav Srivastava
    Ranch Hand

    Joined: Nov 19, 2002
    Posts: 349

    There are only two "objects" in this context: Integers 10 and 99. x, y, z are only references. At "//here" both 10 and 99 have a valid references. I think the answer 0 is correct.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36486
        
      16
    Agree about two objects; even I worked out they were the Integers 10 and 99.

    You mean they remain valid because they haven't gone out of scope yet?
    Rusty Shackleford
    Ranch Hand

    Joined: Jan 03, 2006
    Posts: 490
    Yeah, 0 is correct, I was looking at it backwards.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36486
        
      16
    Yes, I think we have got this sorted out. None because they haven't yet gone out of scope.
    Ls chin
    Ranch Hand

    Joined: Jun 28, 2008
    Posts: 99
    Hi Paul,
    I'm thinking the same thing. Shouldn't z = null; be available for GC? It should, isn't it? What scope is there left for z?

    Originally posted by Paul Yule:
    Isn't z available for GC? When the z Integer references y, y doesn't gain a reference to z does it? So z should be eligible for garbage collection. Perhaps there was suppose to be a line for "y=z"?


    When z Integer references y, y doesn't gain a reference to z? What do you mean?
    Henry Wong
    author
    Sheriff

    Joined: Sep 28, 2004
    Posts: 18117
        
      39

    Hi Paul,
    I'm thinking the same thing. Shouldn't z = null; be available for GC? It should, isn't it? What scope is there left for z?

    When z Integer references y, y doesn't gain a reference to z? What do you mean?


    Keep in mind -- References are *not* eligible for GC. It is the objects that are eligible for GC. So, when z is set equal to y, the object that is previously reachable via y, is now also reachable via z.

    When z is set to null, the object is no long reachable via z, but to be eligible for GC, it must be not reachible. So, is the object that is no longer reachable via z, still reachable?

    Henry


    Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
    Henry Wong
    author
    Sheriff

    Joined: Sep 28, 2004
    Posts: 18117
        
      39

    Isn't z available for GC? When the z Integer references y, y doesn't gain a reference to z does it? So z should be eligible for garbage collection. Perhaps there was suppose to be a line for "y=z"?


    This statement doesn't make any sense. When you set y to z, z is now refering to the same object as y. That's it -- y and z are pointing to the same object.

    There is no reference from y to z, or z to y, or any reference to any other reference. References point to objects, not references.

    Henry
    [ September 12, 2008: Message edited by: Henry Wong ]
    Ls chin
    Ranch Hand

    Joined: Jun 28, 2008
    Posts: 99
    Hi Henry,
    Originally posted by Henry Wong:
    Keep in mind -- References are *not* eligible for GC. It is the objects that are eligible for GC. So, when z is set equal to y, the object that is previously reachable via y, is now also reachable via z.


    Thanks. :-) I was a 'slightly' confused by the reference variable thing. :roll:


    Originally posted by Henry Wong:
    When z is set to null, the object is no long reachable via z, but to be eligible for GC, it must be not reachible. So, is the object that is no longer reachable via z, still reachable?


    I think ~ if there are 2 reference variables pointing to the same object and only one of them is set to null (i.e. z = null), the other reference variable (i.e. y) is still pointing to that object. Hence, the object (= new Integer(99)) will *not* be eligible for GC.

    :-)

    Thanks again!
    Paul Yule
    Ranch Hand

    Joined: May 12, 2008
    Posts: 229
    Okay, gotcha...thanks henry. Do references not take up any space on the heap? I was of the understanding that the pointer itself would also need to be GC'd. It's just under most circumstances this happened at the same time. Thanks again
    Henry Wong
    author
    Sheriff

    Joined: Sep 28, 2004
    Posts: 18117
        
      39

    Originally posted by Paul Yule:
    I was of the understanding that the pointer itself would also need to be GC'd. It's just under most circumstances this happened at the same time.


    If the reference variable is a local variable, then it is part of the stack frame, which will be gone when it goes out of scope.

    If the reference variable is a instance variable, then it will be gone when the object is GC'ed.


    So, to answer you question... yes, it takes up space and needs to be gx'ed, but the GC doesn't have to do anything extra. It is attached to the objects already being GC'ed.

    Henry
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Object eligible for GC?
     
    Similar Threads
    Garbage Collection
    can anyone explain this?
    confused............
    Garbage Collection
    Garbage Collection