Reference Variables on the stack

[Glen Iris]

From my understanding, reference variables live on the heap. Can someone please give me an example of a reference variable that lives on the stack?

[Stephan van Hulst]

Reference variables don't live on the heap. Objects (usually, but not always) live on the heap. Reference variables just point to these objects.

Local variables live on the stack. Fields live where their composing objects live. If the object lives on the stack, so does the field.

[ayush raj]

Refernce variables are a way to reach to the objects created on the heap . Reference variable live on stack and not on heap .

Stephan van Hulst wrote
Objects (usually, but not always) live on the heap

Please site an example for this .

[Stephan van Hulst]

ayush raj wrote:Reference variable live on stack and not on heap.

Not true. Fields live together with their composing objects. If the object lives on the heap, so does the variable.

Please site an example for this .

Well, I can't give you a concrete example, because it depends on the Java implementation, but objects that are created in a method, and never wander outside of that method (by passing them as arguments to other methods, or by assigning them to a field) are very likely to be stored on the stack. This way they are automatically removed from memory once the method call terminates. This takes some pressure off the garbage collector.

[ayush raj]

Instance variables and objects live on heap . Now , if the instance variable is reference one , then it would sure live on heap . But if its a local reference variable , it lives on the stack .

Stephan van Hulst wrote : objects that are created in a method, and never wander outside of that method (by passing them as arguments to other methods, or by assigning them to a field) are very likely to be stored on the stack

For the methods , if a local object is created and a local reference points to it , then the object still is created on the heap while the reference variable lives on stack . When the body of the method is over and if no more reference to the created local object exists , then the object gets eligible to be garbage collected . This is what i think . Please correct me if i am wrong ..

[Joanne Neal]

ayush raj wrote:Please correct me if i am wrong ..

Do a search for escape analysis which was implemented in later updates of Java 6 and in Java 7.

[Henry Wong]

Joanne Neal wrote:

ayush raj wrote:Please correct me if i am wrong ..

Do a search for escape analysis which was implemented in later updates of Java 6 and in Java 7.

There are a few optimizations that take place based on escape analysis, so when you do such research, and it doesn't look like it applies, it probably doesn't. Just keep searching.

Henry

[ayush raj]

Cant understand what you guys are talking about escape sequence !! Point out the actual rule what happens in java in case of objects and references .

[Stephan van Hulst]

There is no rule. It's a trick. It's a small optimization that a particular compiler might employ to reduce the strain on the garbage collector.

Escape analysis refers to a technique where the compiler inspects a method to figure out in what places a method call may return, and what some possible states of the program are when the method returns. This has various useful applications.

One of these applications is that when the new keyword is used to create an object, the object may be stored on the stack, because it's only used temporarily, and it's much easier to clean up the stack than the heap.

[ayush raj]

How should we answer such questions on the exam then , if its asked whether its true/false : an object can live on stack as well as on heap ?

[Stephan van Hulst]

Sorry, I can't help you there. Honestly, I don't think it has much to do with Java anyway. Things like this are more interesting if you want to build your own implementation. I don't know if and why they ask these questions.

[Joanne Neal]

ayush raj wrote:Cant understand what you guys are talking about escape sequence !!

We're not. We're talking about escape analysis.

[Henry Wong]

Stephan van Hulst wrote:There is no rule. It's a trick. It's a small optimization that a particular compiler might employ to reduce the strain on the garbage collector.

Escape analysis refers to a technique where the compiler inspects a method to figure out in what places a method call may return, and what some possible states of the program are when the method returns. This has various useful applications.

One of these applications is that when the new keyword is used to create an object, the object may be stored on the stack, because it's only used temporarily, and it's much easier to clean up the stack than the heap.

Or in another words, can an instance that has been created in a method escape that method? It is actually not that easy, it could be as well hidden as the finalize() method saving a copy of the "this" variable somewhere. The compiler needs to examine the method, along with the target class itself, to make such a determination.

Another cool optimization is, if an instance doesn't escape the method, and the method calls a synchronize method of the target object, do you really need to acquire the lock? Not acquiring the lock is faster than acquiring a lock -- even if the lock grab is uncontested.

Henry

[Henry Wong]

ayush raj wrote:How should we answer such questions on the exam then , if its asked whether its true/false : an object can live on stack as well as on heap ?

I think that the correct answer is to answer it the way that you were taught. After all, the goal is to pass the test... .... just remember to have an open mind, and understand that tests (and knowledge) can be outdated (and you are merely giving the "correct" (but outdated) answer to an outdated test).

Henry

[Glen Iris]

Henry Wong wrote:

ayush raj wrote:How should we answer such questions on the exam then , if its asked whether its true/false : an object can live on stack as well as on heap ?

I think that the correct answer is to answer it the way that you were taught. After all, the goal is to pass the test... .... just remember to have an open mind, and understand that tests (and knowledge) can be outdated (and you are merely giving the "correct" (but outdated) answer to an outdated test).

Henry

So what is the way we were taught?

[Helen Ma]

According to KB's book, p. 184:

Instance variables and objects live on the heap.
Local variables live on the stack

[Bert Bates]

For the purpose of the exam, non-String objects live on the heap. An object is eligible for garbage collection when no live thread has a reference to that object.

As far as the stack goes, understanding the basics of how the stack works might help you answer variable scoping questions.

hth,

Bert