Weird Garbage Collection...

[fatabass]

Hi everyone, here is the code:

package myPackage;

public class Book {
	
	boolean checkedOut = false;
	Book(boolean checkOut){
		checkedOut = checkOut;
	}
	
	void checkIn() {
		checkedOut = false;
	}
	
	void checkedOut() {
		checkedOut = true;
	}
	
	protected void finalize() {
		if(checkedOut)
			System.out.println("Error: Checked out");
	}
}

package myPackage;

public class TerminationCondition {

	public static void main(String[] args) {
		
		for(int i = 0;i<100;i++)
		{
			Book novel = new Book(true);
			novel.checkIn();
			new Book(true);
			System.gc();
		}
	}
}

When I run this, I get different amount of "Error: Checked out" 's in the console every time I run it.
Sometimes I get 100 lines, sometimes only around 20, sometimes around 70 or 80..

Can anyone explain step by step what this code is really doing and what causes this?

Thank you..

[doWhile]

Think threading. The Garbage Collector runs in its own thread. When main exits the program shuts down stopping both threads - wouldn't be surprised to see variable output when you are outputting the results of a race between two threads, and stopping the race prematurely (when main exits).

To illustrate this, sleep the main thread after the for loop for a period of time (using Thread.sleep()) - say for a second, then check the consistency of the output.

[2by4]

gc() is only a request to the VM to run the garbage collection. The system will determine if and how much it does. It will vary according to memory usage.

[fatabass]

is gc() calling finalize?

[JosAH]

is gc() calling finalize?

Yes it does but it calls it only once; this protects the gc against 'resurrection' if the object creates a new reference to itself when it is being finalized (quite sick i.m.h.o.)

kind regards,

Jos

[Tolls]

Yes it does but it calls it only once; this protects the gc against 'resurrection' if the object creates a new reference to itself when it is being finalized (quite sick i.m.h.o.)

kind regards,

Jos

I'd have to reread up on this, but I thought stuff with a finalise() was not necessarily gc'd on a collection run, but stuck off to one side so the finalise() could be executed. This means, though they are marked for gc, they are also marked as having a finalise so are not gc'd straight away (when they would have been without a finalise()).

In other words, finalise() will delay gc for eligible objects.

[JosAH]

I'd have to reread up on this, but I thought stuff with a finalise() was not necessarily gc'd on a collection run, but stuck off to one side so the finalise() could be executed. This means, though they are marked for gc, they are also marked as having a finalise so are not gc'd straight away (when they would have been without a finalise()).

In other words, finalise() will delay gc for eligible objects.

Yep, finalize() postpones the final garbage collection, but before an object is ripped to pieces, its intestines removed and its eyeballs poked out, its finalize() method has definitely run once. The gc keeps a flag, indicating that a finalize() method has been run before; if so, it doesn't run again (to protect against resurrection). There is no guarantee that an object will ever be collected though (System.exit() is an example).

kind regards,

Jos

[2by4]

is gc() calling finalize?

It is very complex...phantom references...weak references...and all manner of stuff. From what I recall, you cannot rely on finalize being called.

[fatabass]

So what exactly is gc doing then ?

[JosAH]

It is very complex...phantom references...weak references...and all manner of stuff. From what I recall, you cannot rely on finalize being called.

Stop spreading vague rumours; you're not helping anyone with it; straight from the JLS:

12.6 Finalization of Class Instances
The class Object has a protected method called finalize; this method can be overridden by other classes. The particular definition of finalize that can be invoked for an object is called the finalizer of that object. Before the storage for an object is reclaimed by the garbage collector, the Java virtual machine will invoke the finalizer of that object.

Finalizers provide a chance to free up resources that cannot be freed automatically by an automatic storage manager. In such situations, simply reclaiming the memory used by an object would not guarantee that the resources it held would be reclaimed.

The Java programming language does not specify how soon a finalizer will be invoked, except to say that it will happen before the storage for the object is reused. Also, the language does not specify which thread will invoke the finalizer for any given object. It is guaranteed, however, that the thread that invokes the finalizer will not be holding any user-visible synchronization locks when the finalizer is invoked. If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates.

Finalizers aren't called in any particular order, nor are they called if their memory need not to be reused (as for the System.exit() call). Read paragraph 12.6. and further for all the details.

Jos

[2by4]

Stop spreading vague rumours; you're not helping anyone with it; straight from the JLS:



Finalizers aren't called in any particular order, nor are they called if their memory need not to be reused (as for the System.exit() call). Read paragraph 12.6. and further for all the details.

Jos

As I said, you cannot rely on finalize being called. The garbage collector does not necessarily collect everything, even when you call gc(). There is also a very complex model with complex categorization of references that the garbage collector uses in determining what to collect.

I don't know why you have called something a rumour and then posted confirmation!

[JosAH]

As I said, you cannot rely on finalize being called. The garbage collector does not necessarily collect everything, even when you call gc(). There is also a very complex model with complex categorization of references that the garbage collector uses in determining what to collect.

I don't know why you have called something a rumour and then posted confirmation!

Learn to read: if the memory taken by an object needs to be used for new objects, the finalizer() (if present) of the old object is called (if not called before). Don't babble if you don't know what you're talking about because it'll only mislead the OP here.

Jos

[2by4]

Learn to read: IF the memory taken by an object needs to be used for new objects, the finalizer() (if present) of the old object is called (if not called before). Don't babble if you don't know what you're talking about because it'll only mislead the OP here.

Jos

You learn to read. Here, I've highlighted it, just for you! Do you know the significance of that IF?

Read this. It may help you..

Cleanup: finalization and garbage collection

Your objects might not get garbage collected.

You might find that the storage for an object never gets released because your program never nears the point of running out of storage. If your program completes and the garbage collector never gets around to releasing the storage for any of your objects, that storage will be returned to the operating system en masse as the program exits. This is a good thing, because garbage collection has some overhead, and if you never do it you never incur that expense.

Now, if you have a useful comment, I am all ears.

[JosAH]

You learn to read. Here, I've highlighted it, just for you! Do you know the significance of that IF?

Read this. It may help you..

Cleanup: finalization and garbage collection



Now, if you have a useful comment, I am all ears.

Don't turn around the argument: I wrote the 'if' part so I know very well what that statement was saying. Please go babbling somewhere else.

Jos

[2by4]

Don't turn around the argument: I wrote the 'if' part so I know very well what that statement was saying. Please go babbling somewhere else.

Jos

Reading between the lines, I am glad you have realised your misconception.

If, in future, you learn to cast you comments more thoughtfully, you will afford yourself the dignity of a graceful exit from your dilemma instead of skidding out on your nose.

My last word on this to you.

Cheers.

[doWhile]

Argument aside...

fatabass, if you have not yet, please read my advice in post 2. I ran your code with a delay after the for loop, and finalize() gets called exactly 100 times - every time. This result should answer your question, and if you have different results please do share. One might expect it to be called 200 times - I recommend the following reading (in particular, the Invisible section) :
http://java.sun.com/docs/books/perfo...PAppGC.fm.html
There are a lot of intricate details to garbage collection, and evidently it causes heated debate, but I would not recommend relying on the finalize method to accomplish important tasks...my .02

[fatabass]

Thank you everyone for your opinions.

I will study on this a little and share my thoughts.