-3

Can someone please tell me how the garbage collection works using this example. The question is how many objects are eligible for garbage collection at the specified point in the program.

interface Animal {
void makeNoise();
}

class Horse implements Animal {
    Long weight = 1200L;
    public void makeNoise() {

        System.out.println("whinny");
   }
}

public class Icelandic extends Horse {
    public void makeNoise() {
        System.out.println("vinny");
    }

    public static void main(String[] args) {
        Icelandic i1 = new Icelandic();
        Icelandic i2 = new Icelandic();
        Icelandic i3 = new Icelandic();
        i3 = i1;
        i1 = i2;
        i2 = null;
        i3 = i1;
//**here**
    }
}
ncst
  • 187
  • 1
  • 1
  • 10
  • 1
    What do you think the answer should be? – Rohit Jain Aug 02 '13 at 12:45
  • 4
    Take pen and paper and start drawing cirles and arrows. That's what helped me a lot understanding it. – Uooo Aug 02 '13 at 12:46
  • Garbage collection is a whole subject in itself. You should search on google. Basically, an object is elligible for GC if it is not referenced anymore OR if the object belongs to an unreachable object cycle. – Arnaud Denoyelle Aug 02 '13 at 12:53
  • 1
    Answering this properly requires a deep look into the Java Language Specification. I assume your "here" is actually supposed to be inside the main method, not after it, but that makes little difference - I'm pretty sure the answer is the same as "how many objects have been constructed". On the other hand a naive approach might assume i1, i2 and i3 are still in scope and prevent GC (I believe this is no longer true). – davmac Aug 02 '13 at 12:53
  • 1
    this smacks of a homework question – GordonM Aug 02 '13 at 13:02
  • Homework questions are OK, as long as they have relevance to some real world programming problem. Not sure this one does, though; it's basically a trivia question. – cHao Aug 02 '13 at 13:05
  • @cHao Yeah, that's what I meant. There's a world of difference between "I'm having a little trouble with a university project and could use a few pointers" and "Do this text book exercise for me". This question reeks of the latter. – GordonM Aug 02 '13 at 13:15
  • Not here to do your homework for you. Give us your best, justify it in every way, and we'll be happy to critique your justifications. – Richard Sitze Aug 05 '13 at 01:59

2 Answers2

2
  • Objects become eligible for garbage collection when they are not reachable. Their reachability is explained in the following link.

You can try this link to understand how objects become eligible for garbage collection and they start drawing diagram for your own. If you face problems, let us know.

Prasad Kharkar
  • 13,410
  • 5
  • 37
  • 56
  • 1
    I don't know why you got a downvote, but I think one of the questions posed and not answered by your link is whether i1, i2 and i3 still count as references at the end of the method despite that they are dead references (not used in the future). – davmac Aug 02 '13 at 12:56
  • Guys, I have posted another answer, I would appreciate if you could confirm if the explanation is good. Thanks – JNL Aug 02 '13 at 13:00
1

Just took it from your code. Just follow the code and you will be good.

        Icelandic i1 = new Icelandic();  // i1 = firstObject --> Location XXXX
        Icelandic i2 = new Icelandic();  // i2 = secondObject --> Location YYYY
        Icelandic i3 = new Icelandic();  // i3 = thirdObject  ---> Location ZZZZ

        i3 = i1;
        // HERE i3 = i1; i3 --> XXXX; i1 --> XXXX; i2 --> YYYY  
        (ZZZZ No reference)

         i1 = i2;
        // Here i1 --> YYYY; i2 --> YYYY; i3 --> XXXX

        i2 = null;
        // Here i2 --> null; i1-->YYYY; i3 --> XXXX

        i3 = i1;
        // Here i1-->YYYY; i2 --> NULL; i3--> YYYY 
       (No reference for XXXX and ZZZZ)

Hope this helps.

Note, Long weight is also an Object. So total of 4 objects eligible for GC. Let me know if it helped.

JNL
  • 4,683
  • 18
  • 29
  • You've missed that Icelandic extends Horse, and each Horse contains a reference to a Long. Your last line (No reference for YYYY and ZZZZ) explicitly contradicts the line above which shows two references to YYYY. Finally, you haven't take into account that i1, i2 and i3 are all dead references. – davmac Aug 02 '13 at 13:04
  • @davmac I believe we have to guess the number of GC eligible objects after the line, i3=i1 and not after main. After main, as the program has been executed everything will be eligible for GC. Also I included the Long object for GC. Edited the answer just before your post. – JNL Aug 02 '13 at 13:07
  • it doesn't matter whether the point is inside the method, the references are still dead and therefore do not prevent GC of their referents. – davmac Aug 02 '13 at 13:08
  • Sorry, I edited the 'No reference for YYYY'. Also note that the Long objects all have the same value, passed in from a compile-time constant. Do you get distinct objects in this case? – Graham Griffiths Aug 02 '13 at 13:09
  • 1
    @GrahamGriffiths, I don't believe that's even specified. See http://docs.oracle.com/javase/specs/jls/se5.0/html/conversions.html#5.1.7 - the constants between -127 and 128 *must* refer to the same object when boxed, but for numbers outside that range reference equality is unspecified. – davmac Aug 02 '13 at 13:11
  • @davmac It does matter if the point is within the metod---no local variable is dead (even those with block scope narrower than the method) until the whole method ends. – Marko Topolnik Aug 02 '13 at 13:12
  • @MarkoTopolnik Do you think the explanation of my answer is good enough to understand? – JNL Aug 02 '13 at 13:14
  • @MarkoTopolnik: If escape analysis detects that references to an object never leave the method, it might be destroyed as part of exiting the method. Which would make it no longer technically eligible for collection, cause it doesn't even exist anymore. – cHao Aug 02 '13 at 13:14
  • @JNL Yes, and it matches what I figured out. – Marko Topolnik Aug 02 '13 at 13:15
  • @MarkoTopolnik I am trying to understand the explanation by chao and davmac. Wonderring if am missing anything. – JNL Aug 02 '13 at 13:16
  • @cHao Yes, many different things can happen. My point is that there is no guarantee that *any* local variable, even if out of scope, is "dead" in the sense of not counting towards the reachability of its referent. – Marko Topolnik Aug 02 '13 at 13:16
  • @MarkoTopolnik: Ah. I just reread all the comments. Sorry for misunderstanding :) – cHao Aug 02 '13 at 13:17
  • @MarkoTopolnik, you don't seem to understand what "dead" means. If a reference is unused at any point in the future then it is dead. Whether or not dead references that are still in scope must prevent GC is up to the Java Language Specification. – davmac Aug 02 '13 at 13:22
  • so the 'clever' answer is that since the weight is over 128 it's impossible to say, because the separate weight objects may or may not point to the same object. Awesome! And I even trolled Jon Skeet to find that out... – Graham Griffiths Aug 02 '13 at 13:23
  • @davmac "Dead" means whatever you imagine it to mean---there is no standard meaning of that term in Java. And the best you'll get in the way of specification is the Java Virtual Machine Specification and the discussion on *frames*. – Marko Topolnik Aug 02 '13 at 13:23
  • @MarkoTopolnik in computer science and in particular program analysis there is a term "Liveness" which specifically refers to whether a value is used or not. See http://en.wikipedia.org/wiki/Live_variable_analysis. Clearly "dead" is the opposite of "live". This is not something I have imagined. – davmac Aug 02 '13 at 13:26
  • although on a modern machine with lots of memory, apparently the refs will likely be shared : "Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K." http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.7 – Graham Griffiths Aug 02 '13 at 13:29
  • @davmac I don't mind if you edit my answer, to explain your point here. You can have your explanation, below my answer. The sole purpose is for everyone being able to learn, incase if we are missing anything. Thanks. – JNL Aug 02 '13 at 13:29
  • @davmac As I said, there is no standard meaning for it *in Java*. I am quite aware that there are other areas where this meaning is defined---for example, in C++ it means something completely different. Now, if we were discussing the JIT compiler here, your meaning would probably have applied. – Marko Topolnik Aug 02 '13 at 13:29
  • @GrahamGriffiths If you review the [source code of OpenJDK's java.lang.Long](http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/lang/Long.java#Long.LongCache.0cache), you'll see that the range -128 to 127 is hardcoded. – Marko Topolnik Aug 02 '13 at 13:32
  • @MarkoTopolnik you're being absurd. If there's no specific meaning for "dead" in _Java_ then in general the meaning for "dead" in all programming languages obviously applies, since Java is a programming language. – davmac Aug 02 '13 at 13:35
  • The JLS has this to say on what objects are reachable: http://docs.oracle.com/javase/specs/jls/se5.0/html/execution.html#12.6 - note specifically the use of the term "active uses" which correspond to liveness. Thus, dead references do not in fact prevent garbage collection. – davmac Aug 02 '13 at 13:38
  • @davmac See for example [this resource](http://books.google.hr/books?id=aJ1av7UFBPwC&pg=PA135&lpg=PA135&dq=C%2B%2B+dead+reference&source=bl&ots=YRhI_sOk2Y&sig=Df14jgzaLqZSi815IPA1UAKUG7E&hl=en&sa=X&ei=vbb7Ufa_OcqItAaEmoCQAw&redir_esc=y#v=onepage&q=C%2B%2B%20dead%20reference&f=false) and then come back to convince me it is absolutely understood what you mean when you come in and use that term with no definition offered. – Marko Topolnik Aug 02 '13 at 13:42
  • @davmac Re-reading your original comment, and taking into account the definition of "dead" you have now introduced, I can re-confirm that the liveness of those variables is irrelevant---and that is precisely because, as far as Java semantics are concerned, the dead/alive distinction *does not exist*. – Marko Topolnik Aug 02 '13 at 13:44
  • @MarkoTopolnik, the link you provide is for C++ where "dead reference" does have a specific meaning slightly different to dead variable. In Java each variable of reference type holds a reference (or null), thus the distinction isn't necessary. If you must argue this point then let me change "dead reference" to "dead variable" in all my above posts and then my main point, that the variables i1 and i2 and i3 do not by themselves prevent GC of the objects that they may refer to, still stands. – davmac Aug 02 '13 at 13:47
  • @davmac It *doesn't stand*: the references *do prevent the GC of their referencs*, or at least *are not guaranteed not to prevent it*. That is the whole point I am making. – Marko Topolnik Aug 02 '13 at 13:49
  • @davmac Specifically, see [this post](http://stackoverflow.com/questions/13531004/java-outofmemoryerror-strange-behaviour) and my answer. It quite poignantly addresses this issue. – Marko Topolnik Aug 02 '13 at 13:53
  • @MarkoTopolnik, final comment on this, the "dead/alive distinction" does exist in Java; see the JLS section I quoted above re reachability. It doesn't specifically use the term "dead" but that hardly matters, as it's a well-known term in program analysis. I'm not sure why you first claimed that "no local variable is dead (even those with block scope narrower than the method) until the whole method ends" if you then want to claim that "dead" is not defined. – davmac Aug 02 '13 at 13:55
  • @MarkoTopolnik, didn't see your previous two comments. That "the references ... at least are not guaranteed not to prevent [GC of their referents]" I agree with, but the question is about _eligibility_ for GC. The references may not be guaranteed not to prevent GC, but they are certainly not guaranteed to prevent it. – davmac Aug 02 '13 at 14:00
  • 1
    @davmac Finally we find out that we are talking about the same thing :) And let's forget the skirmish about "dead" and "alive". – Marko Topolnik Aug 02 '13 at 14:02
  • This was awesome. Specially the articles that were posted helped. – JNL Aug 02 '13 at 14:10
  • wow, learnt so much from all of you experts. – ncst Aug 04 '13 at 19:09
  • @JNL just did that. Got so much to learn but still ended with -10 rep.lol – ncst Aug 04 '13 at 19:40