File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Reference Variables on the stack Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Reference Variables on the stack" Watch "Reference Variables on the stack" New topic
Author

Reference Variables on the stack

Glen Iris
Ranch Hand

Joined: Jul 13, 2011
Posts: 164

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?


OCPJP 6, OCMJD
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3594
    
  14

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
Ranch Hand

Joined: Jan 15, 2012
Posts: 60
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
Bartender

Joined: Sep 20, 2010
Posts: 3594
    
  14

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
Ranch Hand

Joined: Jan 15, 2012
Posts: 60
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
Rancher

Joined: Aug 05, 2005
Posts: 3426
    
  12
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.


Joanne
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18523
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
ayush raj
Ranch Hand

Joined: Jan 15, 2012
Posts: 60
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
Bartender

Joined: Sep 20, 2010
Posts: 3594
    
  14

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
Ranch Hand

Joined: Jan 15, 2012
Posts: 60
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
Bartender

Joined: Sep 20, 2010
Posts: 3594
    
  14

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
Rancher

Joined: Aug 05, 2005
Posts: 3426
    
  12
ayush raj wrote:Cant understand what you guys are talking about escape sequence !!

We're not. We're talking about escape analysis.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18523
    
  40

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
author
Sheriff

Joined: Sep 28, 2004
Posts: 18523
    
  40

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
Ranch Hand

Joined: Jul 13, 2011
Posts: 164

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
Ranch Hand

Joined: Nov 01, 2011
Posts: 451

According to KB's book, p. 184:

Instance variables and objects live on the heap.
Local variables live on the stack
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8803
    
    5
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


Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Reference Variables on the stack
 
Similar Threads
Heaps & Objects
Array Objects
variables on the stack or heap
Reference Variables
K&B - Statement, Cannot understand