• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Memory Allocation Query

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why are the local reference variables stored in Stack? What are the disadvantages of this? Is it true, the main() method is stored in heap not stack? If yes why?
 
Marshal
Posts: 79180
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why do you think you need to know that?
What good would it do, storing local variables on the stack?
Who on earth told you the main method is stored on the heap?
 
Robby Ames
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So what's the need of knowing 'how memory allocation work in java', because we are not going to create a new JVM. But I think it's a good question. In a forum, a users commented on main().
 
Robby Ames
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I googled the query "Why are the local reference variables stored in Stack?", the Google referred me to that forum. I know that method's code stay in heap but method's calls stay in stack.
 
Ranch Hand
Posts: 1609
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Robby Ames wrote:...I know that method's code stay in heap but method's calls stay in stack.



What do you mean by "method's code"? Objects are stored on heap, wherever they are created.
 
Campbell Ritchie
Marshal
Posts: 79180
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Which forum? Give us a link? What did they say? Did anybody disagree?
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Objects live on the heap because the heap is designed to store lots of objects that move in and out of memory fairly frequntly. Code stays n perm gen because perm gen is designed to hold code that doesn't change too much. Parameters live on the stack because the stack is designed to hold a small set of variables that go in and out very very fast and in a FIFO order.

 
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This discussion might help you.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Robby Ames wrote:So what's the need of knowing 'how memory allocation work in java', because we are not going to create a new JVM. But I think it's a good question. In a forum, a users commented on main().


I think what Campbell's trying to say is that this sort of information is highly specialized, and it's doubtful whether it will ever be of any use to you as a programmer.

But, simply put, the memory requirements for objects and methods are very different, and stack frames as a paradigm for method memory have been around for a long time.
Objects need to be garbage-collected, method memory: generally not; objects are shared (and so may need to be synchronized), methods aren't; speed (relatively speaking) is far less important for objects than it is for methods.
And that's just scratching the surface.

And knowing these things, while it might be interesting, is of very little use to you as a programmer. You can't change any of it, and the chances of it making any difference to how you write a program are almost nil - indeed, you should never write programs that rely on something you may have read about it, because it's quite possible that it will change in a future release - the Java memory model has already changed many times since the language first came out.

Winston
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Winston on this, but I also understand the difficulty new programmers can have in believing that the answers to questions like these are not very important to a Java programmer (at least, not to a new one). As a C guy of many years' experience, I know it's hard to let go of all the memory-model stuff that truly is important to good C programming. When a newcomer to Java asks about the memory model (or the garbage collector, or any of those things that seem to fascinate newcomers despite being relatively unimportant), I believe the most useful response is not just, "You don't need to be worried about that, " but, rather, "You don't need to be worried about that because [reason why Java makes this unimportant, despite the many late nights you'll never get back again owing to the fact that not all malloc() calls allocate heap space in the same way]."

For myself, I enjoy reading the replies that do that, as it helps me understand more each time about the basics of the language.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:I believe the most useful response is not just, "You don't need to be worried about that, " but, rather, "You don't need to be worried about that because [reason why Java makes this unimportant...]."


@Robby: Stevens is quite right, and I should probably have said that it's of very little use to you as a Java programmer.

Winston
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While we're on the topic of beginners (or, more generally, tutelage), I'd like to ask a somewhat off-topic question: what's the best source of guidance for an accomplished procedural programmer seeking to learn OOP?

Before anyone answers, let me enlarge on my question a bit. I have read a dozen books, essays, sites, all about how you can create a Vehicle class and then subclass Boat, Car, InnerTube, and so on from that. I do a lot of subclassing in my programs, but never anything along those lines. It is always to extend the functionality of JPanel or to create a concrete class extended from AbstractAction, that sort of thing. Much more useful, along those lines, has been to understand how interfaces work, so I can pass different objects to methods expecting them to have implemented an interface without knowing (or caring) what class the object actually is.

Likewise, I find advice like, "keep your objects close to the data," and so on, vague to the point of worthlessness. I tried to get some help from "OOP Demystified," but it seemed obsessed with artificial subclasses and folksy aphorisms instead of anything I could recognize as a definite methodology.

My frustration grows from the fact that the particular application I have just doesn't seem to have that much data to encapsulate, yet two of my classes are already thousands of lines long. What it does is manage a big set of BMP files (you know, Windows picture files). Yes, that's a lot of data, but it all comes down to a lot of one kind of data. I have a camera to capture new BMPs, and then, more or less, one big list of them all, into which I can insert new ones, from which I can delete existing ones, and so on. I need to navigate through them, a bit like an old Moviola machine, so I have GUI operations for "go to first," "move forward one," and so on. The code just keeps adding up as I add new operations. But (and I think my conceptual problem lies here, maybe), I am having a hard time creating objects to support operations. Sure, if I had a Vehicle class, and below that I had a DieselTruck class and an ElectricCar class, I could see how the former might have a fillTank method while the latter might have a chargeBattery method (well, actually, both ought to be overriding a "replenishEnergySupply" method, shouldn't they?), but that's not a helpful paradigm when I have lots and lots of operations all intended to operate on the same type of data.

Is that, then, a valid question? That is, does it make sense to ask, "How can I create objects to support operations instead of to encapsulate data?" Am I even on a meaningful line of inquiry here?
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:Is that, then, a valid question? That is, does it make sense to ask, "How can I create objects to support operations instead of to encapsulate data?" Am I even on a meaningful line of inquiry here?


I'm not sure, but I suspect that you're having the same problem as I did when I first started programming in C++ - understanding the OO paradigm.

And I hate to say, but it took 8 years, two languages (C++ and Java) and a "moment of clarity" (and believe me, I've had precious few of those in my life) to finally "get it".

One thing that I've found quite useful is a description of the sort of problem that lends itself to OO, but NOT to procedural analysis; of which the simplest one I know is the Traffic Light problem.

Simply stated it goes as follows:
You have a road intersection (ie, a crossroads) with four entrance lanes, each of which has a pressure switch for detecting vehicles entering the intersection.
1. Write a Java application that controls the traffic lights and pressure switches for the intersection so as to maximize traffic flow.
2. Update that same application to provide switches and lights for a left-turn (or right-turn in the UK) lane in all directions.

Obviously, you need other values (which you can probably supply yourself) to be able to work out how to properly maximise the flow, but its the control part that's important. And the problems is that if you try to think about it in terms of "Car A comes along Lane 1, then Car B comes along Lane 2..." you'll end up in the loony bin. Start thinking in terms of cooperating objects (your traffic lights and switches; and maybe a Master controller) though, and you'll be well on the way to a solution.

Winston
 
Jayesh A Lalwani
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:

And I hate to say, but it took 8 years, two languages (C++ and Java) and a "moment of clarity" (and believe me, I've had precious few of those in my life) to finally "get it".



Same thing happenned with me too.. For several months I read and reread Stroustroup's book. I slept with it under my pillow, and I didn't get it. One day, only way back home from class, I was trying not to doze off on the bus, and it clicked. It's like the scene in the Matrix where they plugin Neo and then he comes out and says "I know Kung Fu". It was like that.

However!! that didn;t stop me from royally messing up my first project. Getting OOP is one thing. Using it effectively is another. For most people, I reccommend not to worry about OOPing their design too much. Aim for simplicity and maintainability.
 
Robby Ames
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Akhilesh Trivedi wrote:

Robby Ames wrote:...I know that method's code stay in heap but method's calls stay in stack.



What do you mean by "method's code"? Objects are stored on heap, wherever they are created.


Ok.. read this:

Stevens Miller wrote:This discussion might help you.

 
Robby Ames
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Which forum? Give us a link? What did they say? Did anybody disagree?



I read it on stackoverflow(most probably). For the link, I have to search it again. Nobody was disagree(reason may be: his comment was the last), that's why I asked this question.
 
Robby Ames
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:
And that's just scratching the surface.

And knowing these things, while it might be interesting, is of very little use to you as a programmer. You can't change any of it, and the chances of it making any difference to how you write a program are almost nil - indeed, you should never write programs that rely on something you may have read about it, because it's quite possible that it will change in a future release - the Java memory model has already changed many times since the language first came out.

Winston



I know, it may not be useful in programming but it will definitely help me to understand the language in a better way.
 
Robby Ames
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:This discussion might help you.


I posted the query after reading many forums including that link.


Thanks! Jayesh and Winston for your reply. Please throw some light on its disadvantages.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Robby Ames wrote:I know, it may not be useful in programming but it will definitely help me to understand the language in a better way.


I disagree. What it might help you to do is understand how the JVM works, but it certainly won't help you understand how to use the language - indeed it may be more of a distraction than anything. It also runs contrary to the whole ethos of Java, which is to hide these things from you so you don't have to worry about them.

My suggestion: re-read Stevens' post because, coming from C/C++, both he and I have been through this business of having to "let go" of all that memory stuff.

But if you really feel you must know more about this, you have little choice but to read the relevant parts of the JLS and JVM specs - and I warn you: they're pretty dry.

There are probably also general books out there about language and system memory structures, but I'm afraid I can't really advise, since it's been literally decades since I've ever had to worry about that sort of stuff (and for a lot of that time I was a System Administrator).

HIH

Winston
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yup, Winston is making an important, subtle distinction: memory management is the business of the JVM, not of the language. At the risk of oversimplification, one could even say that Java, as a language, is completely disconnected from how the JVM manages memory. That is, one's code is not written in any way that depends on how memory is managed. The programmer generally is going to assume that released memory returns to the available pool immediately (indeed, I would wager that most programmers just write their code as though memory were both free and limitless, regardless of how released memory is treated). Now, as lots of Java programs make use of multi-threading, one does have to know some things about memory models (I am thinking of the basics of why a variable shared between threads might have to be declared volatile, for example). But that's not the same as knowing how the heap and the stack are used. Where Java gets its memory and what happens to that memory when a Java application no longer needs it is just not relevant to learning Java itself.

But...

As you are reading here, C/C++ programmers who are new to Java might tend, in all innocence, to ask, "Where are the pointers?" When they get over the shock of finding out that Java has no pointers, and begin to understand what a "reference" is, they naturally wonder why there are all those calls to new, with no matching call to something that undoes what new does. That is, if new is Java's "malloc()," where is Java's "free()"? Java has no "free()," as its function is incorporated into the relationship between objects and their scopes. That (again, to oversimplify) appears to be the essence of what it means to say that Java is a "managed" language.

Those of us making the crossing from unmanaged languages to managed ones might then ask, "But, but... how is that possible?" It does seem kind of astounding that one of the biggest sources of concern C/C++ programmers have, particulary some of the more advanced C/C++ programmers, just does not exist in Java (yes, yes, there are exceptions, I admit it... just hush up about those for now, okay?). Answering the question of how it is possible does not improve one's understanding of the language directly, but it can help one overcome a barrier to (for lack of a better way to put it) one's ability to believe in the language.

I went through this myself, having to know at least enough about the Garbage Collector to get over the hump represented by the notion that a language could have a keyword like new, yet never call upon me as a programmer to do anything explicitly that would reverse the effect of new. To that extent, I am sympathetic to anyone else who, new to Java, asks about the GC, memory management, the model, and so on. But, in the end, most of that stuff really doesn't matter. Hard as it is to believe, that's the answer you're going to reach, so don't be too put off if that's the answer you hear when you first start asking. If one needs to know how it can be that such stuff doesn't matter, that's a different question, but pursuing the answer to that one is probably the more helpful use of a new Java programmer's time. (At least, it is if that programmer is throwing off the shackles of an unmanaged language; if they are new to programming entirely, I might tend to wonder how their priorities got set for them, but that's a topic for another thread, I hope.)
 
Robby Ames
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks! Winston and Thanks! Stevens. Guys, as I already told you: "I know, it may not be useful in programming". I know you guys have years of experience in programming. But I find it strange that you all are explaining "why shouldn't I care for memory allocation in java" but that I already know. I was hoping for a precise answer from the experienced guys like you. Because it's(reading which you already know) also a waste of time. I'm only asking for a drop of your knowledge.
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Robby Ames wrote: I'm only asking for a drop of your knowledge.


Heh. Drops are relative. For some of these other guys, it may be a drop. From me, you've just had the full bucket.
 
Robby Ames
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:

Robby Ames wrote: I'm only asking for a drop of your knowledge.


Heh. Drops are relative. For some of these other guys, it may be a drop. From me, you've just had the full bucket.


Stevens, It seems you missed this line:

Robby Ames wrote:I was hoping for a precise answer from the experienced guys like you.


But anyway.. Thanks!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic