GC

[manasa teja]

Assume that the following lines of code compiles fine.

 public void somemethod {
for(i=0;i<5;i++)
                {
String s = new String();
}
 }
 

How many objects are eligible for gc after this code is executed.
is it 4 or 3??
please explain?
[ August 12, 2002: Message edited by: Murthy Ram ]

[Valentin Crettaz]

Looking at the code below we can see that 5 objects are gced.

public class gc {
public static void main(String args[]){
for(int i=0;i<5;i++){
Obj s = new Obj(""+i);
}
System.gc();
try{
Thread.sleep(3000);
}catch(Exception e){}
}
}
class Obj {
String name;
public Obj(String name){
this.name = name;
}
protected void finalize(){
System.out.println("finalizing "+this.name);
}
}

Output:
finalizing 0
finalizing 1
finalizing 2
finalizing 3
finalizing 4
The reason is because the objects are in the scope of the for loop. Once an iteration is over, the created object is out of scope and can thus be garbage collected.

[manasa teja]

thanks Val!!!
I have not given importance to the scope of the variable...
I got it now..

[Valentin Crettaz]

One more thing:
be aware that if instead of having
String s = new String();
you have
String s = "someliteral";
no objects are garbage collected because string literals are automatically interned in the private string pool.

[manasa teja]

Yes Val!!! Thanks for information!!

you have
String s = "someliteral";
no objects are garbage collected because string literals are automatically interned in the private string pool.

[Ron Newman]

Also, while that program with a finalize() method will probably produce the result you give, there is no guarantee of it. The garbage collector may or may not run, and may or may not decide to collect those particular objects.

[Anthony Villanueva]

Try this code from Mughal. It takes 2 arguments: the number of objects and the size. If you make the numbers high enough, you should see some of the objects garbage collected ("Bye!").

class SuperBlob {
static int idCounter;
static int population;

protected int blobId;

public SuperBlob() {
blobId = idCounter++;
++population;
}
protected void finalize() throws Throwable {
super.finalize();
System.out.println(blobId + ": Bye");
--population;
}
}
class Blob extends SuperBlob {
int[] fat;
public Blob(int bloatedness) {
fat = new int[bloatedness];
System.out.println(blobId + ": Hello");
}
public void finalize(String val) throws Throwable {
super.finalize();
}
}
public class Finalizers {
public static void main(String[] args) {
int blobsRequired, blobSize;
try {
blobsRequired = Integer.parseInt(args[0]);
blobSize = Integer.parseInt(args[1]);
} catch (IndexOutOfBoundsException e) {
System.err.println("Usage: Finalizers <number of blobs> <blob size>");
return;
}
for (int i=0; i<blobsRequired; ++i) {
new Blob(blobSize);
}
System.out.println(SuperBlob.population + " blobs Alive");
}
}

[Jose Botella]

Does Mughal justify the call super.finalize() within a class that extends from Object? I mean finalize in Object does nothing.

[Ron Newman]

Since garbage collection runs in a separate thread, I'd be a little concerned abuot synchronization. Declaring the "population" variable volatile might be sufficient to allay that concern.

[Anthony Villanueva]

Does Mughal justify the call super.finalize() within a class that extends from Object?

No, he didn't, although it can be argued that he was demonstrating finalizer chaining.

I mean finalize in Object does nothing.

Agreed. Force of habit, I guess
Anyway, it's on page 253 for those interested.
[ August 12, 2002: Message edited by: Anthony Villanueva ]

[Valentin Crettaz]

Also, while that program with a finalize() method will probably produce the result you give, there is no guarantee of it. -- Ron Newman
That goes without saying That was just for demonstration purposes.

[Jose Botella]

Funny, because Bruce Eckel also has an example in page 333, in Thinking in Java, which calls the finalize method of Object. However the program runs the same without it. For demonstrating finalization chaining only the calls to super.finalize from the rest of the subclasses are needed.
-------------
Placing volatile doesn't affect the behaviour of the program.
There is some populations count left at the end of the program. But this has nothing to with a threading problem. It is due to the g.c. not ending its job before the program terminates. Calling System.gc() after the for loop zeroes the population count.
The API for Object.finalize doesn't guarantee which thread will invoke finalize.
However using jdb to see the threads of the main method of a simple program yields:

main[1] where all
CompileThread0:
Signal Dispatcher:
Finalizer:
[1] java.lang.Object.wait (native method)
[2] java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:111)
[3] java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:127)
[4] java.lang.ref.Finalizer$FinalizerThread.run (Finalizer.java:159)
Reference Handler:
[1] java.lang.Object.wait (native method)
[2] java.lang.Object.wait (Object.java:426)
[3] java.lang.ref.Reference$ReferenceHandler.run (Reference.java:113)
main:
[1] Test2.main (Test2.java:3)
main[1] cont

Going to the source code for the class Finalizer, the thread FinalizerThread is loaded in a static block, given the max. priority minus two, set to deamon and started.