• Post Reply Bookmark Topic Watch Topic
  • New Topic

Stack and Heap understand  RSS feed

 
Justin Robbins
Ranch Hand
Posts: 121
2
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all!

kind of confused on the whole idea behind the Stack and Heap. So essentially we have two areas of memory/RAM in a computer. The Stack holds onto the eight primitive data types and the references to objects. Kind of trying to conceptualize this. So if we create a String:



So when we go to compile Jave sets up these partitions of memory for these objects, right? so since String is an object that goes to the heap. What happens to the variable references s1 and s2 though, do they live on the heap? The way I see it is that the heap is just a temporary location? where many things can be killed off if they stop pointing to things.

So s1 ----> String parition ----> "Bob"

s2 ----> String parition ----> "Sarah"

THEN

s2 ----> s1;

What does that mean exactly? does the object Sarah lose it's connect and now s1 is actually a variable reference to the String object named "Bob"?


Also, a little confused about the use of == and.equals
So the way I've come to understand them is that == compares if two objects share the same memory location in the heap, and .equals compares if two objects are the same value.

would like to check my understanding with a few examples


EX1:


Are they still seperate objets automatically even w/o using the 'new' keyword?


EX2:



EX3:



EX4:



EX5:



So then overall
== is checking if the refernces are pointing to the same object is memory
.equals checks if they are the same value


So then == takes on two functionalities, because when use it with two objects it's comparing if the reference variabls are pointing to the same object. But when dealing with ints it's only a comparision operator of value, is that right?
Would that mean that .equals() also has two functionalities with ints?


Also. rather than starting a new thread I thought I'd ask this here
When we have a String it's called an immutable class, so it cannot be changed. Probably some fundamental confusion with an easy answer but if we have



Doesn't that mean we've changed it Bob to Sarah so the String has been changed.


When we write int, boolean, char do those all stack within the stack? if so then where do the variables of those go like say int num = 3; where does the variable 'num' live? and where does the varibles for Strings live?


Please help
Thank you
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Justin Robbins wrote:So essentially we have two areas of memory/RAM in a computer.

No. The Java Virtual Machine (JVM) has areas of memory that it treats differently. It has nothing to do with the computer you're running it on, or its operating system.

So if we create a String...we go to compile Jave sets up these partitions of memory for these objects, right?

Wrong, because what you wrote won't compile. And if you got it right, it would only "cache" two Strings: "Bob", and "Sarah". Everything else is completely immaterial to what gets stored.

What happens to the variable references s1 and s2 though, do they live on the heap? The way I see it is that the heap is just a temporary location? where many things can be killed off if they stop pointing to things....

You know what? Don't Sweat It.

And I don't say this to sound superior, but simply because it doesn't matter. If you run into this as an exam question, there are only two things to remember:
1. Objects are ALWAYS stored in the heap (there is only one) - and that includes any members they contain, be they references to other objects or primitives.
2. Parameter values - ie, references to objects, or primitive values passed to a method that you call - are stored in a stack.

But the ONLY reason you will ever need to know this is to answer an exam question; they make absolutely NO difference to you as a programmer; but if you start agonizing about them, it will distract you from your primary task - which is to write good, clear, readable Java code.
Create objects, call methods, do what you want; and let the Java garbage collector deal with what you leave behind. That's what it's there for.

HIH

Winston
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
You know what? Don't Sweat It.
...
your primary task ... is to write good, clear, readable Java code.

Amen and +1 to that!

Seriously, trying to understand the heap and the stack as a beginner is like trying to understand the fuel injector and catalytic converter of your car when you're just trying to learn how to drive. Focus on learning what Winston said is your primary task.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Other than setting their sizes at run-time when the JVM is started (in those cases where the default values aren't optimal), can anyone think of a context in which knowing which stores what could even be put to any use?
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Justin Robbins wrote:
Doesn't that mean we've changed it Bob to Sarah so the String has been changed.

No. You have three things here:

1. s1 - a reference to a String object
2. "Bob" - a String object
3. "Sarah" - another String object

In the first line, you make s1 refer to the "Bob" String object
In the second line, you make s1 refer to the "Sarah" String object
Only s1 has been changed. The String objects "Bob" and "Sarah" have not changed.

A visual representation of what's happening:

Line 1:
"Bob" <-- s1
"Sarah"

Line 2:
"Bob"
"Sarah" <-- s1

This is one of the few times where you have to remember that variables that reference objects ARE NOT the objects themselves. In all other cases, you can treat variables as if they ARE the objects themselves.

It's kind of the same idea as with Magritte's famous "The Treachery of Images". What you see in the painting is NOT a pipe. It's an image of a pipe. But if you ask anyone what it is, they will probably say "It's a pipe." The mindset where you see the painting as an image of a pipe is the same mindset you have when you see s1 as a reference to a String. The mindset where you see the painting as a pipe is the same mindset you have when you see s1 as a String.

When we write int, boolean, char do those all stack within the stack? if so then where do the variables of those go like say int num = 3; where does the variable 'num' live? and where does the varibles for Strings live?

Don't overthink this because you'll only confuse yourself more. At this point in your learning, it's less important to know where these things are stored in memory. What's important to understand is the difference between objects and object references and when you shoul treat an object reference as if it was the object itself and when you have to remember that it's really only a reference to an object. Primitive variables can ALWAYS be considered to be the actual values themselves.
 
Steffe Wilson
Ranch Hand
Posts: 165
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote: there are only two things to remember:
1. Objects are ALWAYS stored in the heap (there is only one) - and that includes any members they contain, be they references to other objects or primitives.
2. Parameter values - ie, references to objects, or primitive values passed to a method that you call - are stored in a stack.

Agreed, but also:
3. Method local variables - ie, references to objects, or primitive values that are defined within a method - are also stored on the stack.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This code might lead you to think that a String is in fact mutable.

In this case, you need to remember that s1 is just a reference to a String object (use the "It's NOT a pipe, it's an IMAGE of a pipe" mindset I mentioned before). The "Bob" String object was NOT changed in the above code. Here's what actually happens:

Line 1:
"Bob" <-- s1

Line 2:
"Bob"
" the Builder"
"Bob the Builder" <-- s1

On line 2, Java will create an entirely new String object from the two Strings "Bob" and " the Builder" and then make the variable s1 reference that new String object. The String objects "Bob" and " the Builder" are still unchanged. And again, don't overthink things right now and worry about what happens to those two String objects.

This code might make the immutability of Strings more evident to you:

Lines 2, 7, and 10 each create a new String object.

Line 2 makes the variable s2 reference a new String object
Lines 7 and 10 just pass a reference to a new String object to the System.out.println() method.

Lines 4 and 8 show that the String object, "Bob", remains unchanged
Line 11 shows that the String object, "Bob the Builder", remains unchanged
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stevens Miller wrote:Other than setting their sizes at run-time when the JVM is started (in those cases where the default values aren't optimal), can anyone think of a context in which knowing which stores what could even be put to any use?

Well I'd certainly say that they're parts of the "classic" execution paradigm - stacks as a method of storing return points for many layers of execution, and heaps as simple (and fast) mutable structures for indirect addressing - so in that respect, I think they're useful "background" information.

But as something you need to know (or worry) about to write good Java code? Probably not...and at too early a stage they may even be a distraction.

Winston
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:. . . understand the fuel injector and catalytic converter of your car when you're just trying to learn how to drive. . . .
The only thing you really need to know about fuel in your car is how much you have left. Similarly, the only thing you need to know about the stack and the heap is that they take care of themselves automatically.

Well, maybe you need to remember whether you use electricity LPG petrol or diesel and how much it costs, too.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:The only thing you really need to know about fuel in your car is how much you have left. Similarly, the only thing you need to know about the stack and the heap is that they take care of themselves automatically.

Well, maybe you need to remember whether you use electricity LPG petrol or diesel and how much it costs, too.


I'm an old C programmer. We just walk.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stevens Miller wrote:
Campbell Ritchie wrote:The only thing you really need to know about fuel in your car is how much you have left. Similarly, the only thing you need to know about the stack and the heap is that they take care of themselves automatically.

Well, maybe you need to remember whether you use electricity LPG petrol or diesel and how much it costs, too.


I'm an old C programmer. We just walk.


Good C programmers have to clean up after themselves. Java programmers just leave the garbage collection to somebody else. Maybe that explains a few things.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:Well I'd certainly say that they're parts of the "classic" execution paradigm - stacks as a method of storing return points for many layers of execution, and heaps as simple (and fast) mutable structures for indirect addressing - so in that respect, I think they're useful "background" information.

But as something you need to know (or worry) about to write good Java code? Probably not...and at too early a stage they may even be a distraction.

Don't overlook Steffe's observation: it's common for the values of method-local variables to reside in the stack, though one must be mindful of the fact that a reference is a value too. While it's not mandatory, every C compiler whose internal behavior I knew operated this way.

That said, I believe Winston is utterly correct: there's no reason for a Java programmer, most especially an early Java programmer, to know they even exist.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:. . . Good C programmers have to clean up after themselves. Java programmers just leave the garbage collection to somebody else. Maybe that explains a few things.
Did your Mum tell you that sort of thing when you were young?

t might work with real‑life messes, but doing your own garbage collection is counter intuitive. Rather like when I asked the Missus what had happened to some parts for the lawnmower:-
They were well taken care of, Campbell. They went into the recycling, not the rubbish.
Doing it yourself works well for some things...

Not for garbage collection.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Junilu Lacar wrote:. . . Good C programmers have to clean up after themselves. Java programmers just leave the garbage collection to somebody else. Maybe that explains a few things.
Did your Mum tell you that sort of thing when you were young?

t might work with real‑life messes, but doing your own garbage collection is counter intuitive. ... Doing it yourself works well for some things...

Not for garbage collection.

I was referring to paying attention to little details.

There's one story that goes something like this:

A tourist was so impressed by how well-kept the royal grounds were that when they got a chance to speak to the head groundskeeper, the tourist had to ask "It must take a lot of effort to keep everything so nice and trim, doesn't it?" The groundskeeper replied, "We do have a few people on staff but it really doesn't take much more effort than it does for you with your yard." The tourist says, "I don't believe that for one minute. C'mon, what's your secret?" The groundskeeper replied, "Nothing really. You just have to mow a bit now and then, clip a bit here and there, and regularly clear away old and dead things. When you've done that for a few hundred years then you'll have a yard that looks just as nice as this!"

I think the ability to deal with big problems starts with diligence in taking care of the little details. Like with good C programmers who take care to clean up after themselves, having good code hygiene habits tends to carry over to other things. I'm glad we don't have to collect the garbage ourselves in Java but I also think that too many Java programmers don't pay enough attention to the little details in their programs, like formatting and using good names, and those poor code hygiene habits carry over and are evident in other things in their work.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:I'm glad we don't have to collect the garbage ourselves in Java but I also think that too many Java programmers don't pay enough attention to the little details in their programs, like formatting and using good names, and those poor code hygiene habits carry over and are evident in other things in their work.

Agreed! Why, I hear some Java programmers don't even use a lot of comments!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!