Garbage collection

[Saibabaa Pragada]

Hi, This is from whizlabs.

1. A finalize() may NOT be invoked explicitly. --> FALSE..Why ? We are able to call based on first code snippet.
2. the finalize()method declared in class Object takes no action --> True..WHY ?? How finalize() is called and where is the code for finalize() ?
3. Some reference variables live on stack and some live on the heap (when object has a reference variable, the reference
variable live inside object not on the heap) --> true..What is the meaning ? It should live on the heap know ??

class Question05_Ask {
    void hello() throws Throwable{
	super.finalize();
    }
}
//Object class has defined finalize() as given below
protected void finalize() throws Throwable { }

[Prasad Kharkar]

Saibabaa Pragada wrote:
3. Some reference variables live on stack and some live on the heap (when object has a reference variable, the reference
variable live inside object not on the heap) --> true..What is the meaning ? It should live on the heap know ??

The instance reference variables live on the heap and the local reference variables live on the stack
as stack is created by method calls and local variables are created and destroyed when a method gets called and ends

hth
happy prparation

[Stephan van Hulst]

1) I'm not exactly sure what the exam is saying here. It says the answer is false, but it should probably be true. Fact of the matter is, finalize() *can* be called explicitly, but you shouldn't! The finalize() method gets called automatically when the object is released by the garbage collector.

2) finalize() is declared in Object, but this method does absolutely nothing at all. It's just an empty method, and it's there so it can be overridden. Some classes hold system resources, like a stream to a file, or a connection to a database. These classes may override finalize() to release these resources as soon as they are garbage collected. Resources should always be explicitly released (for example, you should always explicitly call close() on an InputStream when you are done with it), but the finalize() method provides a safety net (a very unreliable one) to release these resources when the programmer forgets to release them explicitly.

3) The heap is the part of memory where all your objects are, and all your class and instance members. The stack is a small piece of memory where the local variables of the invoked methods are being kept. So the stack is where local variables are temporarily stored until the method is done, and the heap holds everything else.

[Saibabaa Pragada]

Hi Stephan, I am always thrilled to see your answers. Even though you joined recently, you are posting wonderful responses. Good job . Back to Point#3, when object has a reference variable, the reference variable live inside object not on the heap --> You mentioned reference variable lives on the heap. If so, answer should be FALSE know ?

[Stephan van Hulst]

Thank you, I am very pleased that my answers are appreciated
Please do not take my answers without questioning though. I am a student, and have little professional experience. Most of what I know is from hobby projects.

3) I am not exactly sure, but what I think they mean is that member fields are not stored as separate entities on the heap. They are part of the data that makes up the object, which has an address on the heap.
I guess it depends on how you look at it. I would say the references are on the heap, but as part of the object.

[Mohamed Sanaulla]

For the point #3- Agree with Stephan.
Adding to it- If the Object reference is part of the method declaration (local declaration)- then the reference will be on the Stack (along with the other local variables), but the actual instance is allocated on the heap.
If the Reference is a member variable then it will be a part of the instance and will be in the heap.

I think Head First Java explains this with some neat diagrams.