Use Memory in Java

[Luca Olivieri]

Hi guys,

i'm studying the memory in java and i learned that:

1) local variable are in the stack
2) instance variable and object are in the heap

where are in the memory static members? and the code of methods?

Is there some useful documentation?

thank you very much

[Campbell Ritchie]

Welcome to the Ranch

That is one of the things you do not actually need to know.

[Luca Olivieri]

Campbell Ritchie wrote:Welcome to the Ranch

That is one of the things you do not actually need to know.

Thank Ritchie,

I think it was wrong section, I'm not new in Java and I would like to improve my knowledge.

Manuals where I studied Java have not I ever speak of memory for static members and so I'm trying to search the web of explanation.

How can I move my post in a section more appropriate?

[Campbell Ritchie]

You have looked in the wrong manual. Try the BCEL manual which will tell you that static fields live in the Class<Foo> object. (I think.)

[Winston Gutkowski]

Luca Olivieri wrote:Manuals where I studied Java have not I ever speak of memory for static members...

Because, as has already been said, it is something that most Java programmer's simply never need to know - and furthermore, might be different for different JVMs or architectures (I don't know).

If you really feel that you must know this, don't let me stop you; but I suspect that there are more productive things you could study if you want to become a better programmer - such as design patterns.

Winston

[Tim Holloway]

In my youth, when I wasn't busy dodging hungry dinosaurs and I programmed IBM mainframes in assembly language, I knew where everything was and how big it was. Heck, I didn't have a choice. There weren't any pre-supplied mechanisms to construct and manage stuff outside of the relatively crude OS memory manager system.

When I got to Java, I threw all that stuff out the window. A JVM is a very complex place and it was designed to operate optimally when programmed without any assumptions as to "efficiency". In fact, many of my old tricks could confuse the built-in optimizers and could potentially result in code that was less efficient overall.

I still concern myself with resources, but it's no longer a primary job. I do look for efficient algorithms at the high levels, but I avoid messing around with the mid/low-level stuff unless there's an obvious need based on real-life operating statistics.

Even allowing for all the mechanisms that are optimizing things for me, computer resources have become so cheap that Management doesn't want me "wasting time" on un-necessary optimization. In fact, I'm fairly sure that the recently announced $5 Raspberry Pi Zero card computer can emulate the same mainframe I used back in 1986 faster than the original 6x12x3 foot CPU ran natively and the Pi Zero has about 256 times as much RAM.

[Steffe Wilson]

Luca Olivieri wrote:where are in the memory static members? and the code of methods?
Is there some useful documentation?

Good question. I'm always interested in how things work too.
Take a look at the JVM Spec, esp. section 2.5 on run time data areas.
http://docs.oracle.com/javase/specs/

[Winston Gutkowski]

Steffe Wilson wrote:Good question. I'm always interested in how things work too...

Me too, but not as much as I used to be when I was a C programmer.

And like Tim, I found I had to "let go" of a lot of that stuff when I started using Java (although I suspect it took me longer than him ), not because it isn't interesting, but - in the main - because it isn't relevant.

I liken what Tim says about "old tricks" to configuring a server (I was a systems admin for 15 years): Back in the day, there were all sorts of tools around for making disk access faster and more secure, like mirroring and striping and parity disks; but then databases started building similar things into their own products and - lo and behold - they started running slower because the two things, while nominally trying to do the same thing, were actually working against each other.

So, @Luca: by all means read about memory usage if it rocks your boat (although the JVM spec is pretty dry stuff), but try not to bring any presumptions from what you read into your code.

Winston

[Steffe Wilson]

Winston Gutkowski wrote: - in the main - because it isn't relevant.

From a development perspective I would agree with you, knowing the bigger picture was much more relevant, pretty much essential, in the days of C. But I still believe it is beneficial now to know the bigger picture, even with java - because knowing what goes on around your application is enormously useful in solving problems when things go wrong and software doesn't behave as expected.

Winston Gutkowski wrote:
I liken what Tim says about "old tricks" to configuring a server (I was a systems admin for 15 years): Back in the day, there were all sorts of tools around for making disk access faster and more secure, like mirroring and striping and parity disks; but then databases started building similar things into their own products and - lo and behold - they started running slower because the two things, while nominally trying to do the same thing, were actually working against each other.

You can look at this example from a different perspective - the problem was solved precisely because someone knew the bigger picture - someone knew what the database was doing internally.