Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (798)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (865)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  How memory works?  (Read 14950 times)
0 Members and 1 Guest are viewing this topic.
Offline matanui159

JGO Coder


Medals: 11
Projects: 1
Exp: 10-12 months


Aww... So cute...


« Posted 2014-11-14 06:39:55 »

This doesn't really have that much to do with Java or proramming in general... It is just a question that has been on my mind lately and this is probably the best place to ask... I already know how memory works in binary and how there is read and write commands and busses... But I want to know, when the program makes a new value to hold in memory, the memory assigns a location to put that value. But how does the program know where that location is? And how does the program remember that? Another memory point? How does this work?

Is it sad that I still get a fright when the computer beeps at me...
Offline richierich
« Reply #1 - Posted 2014-11-14 09:42:53 »

Program: Dear Memory, I have this value 12345, do you have somewhere to store it?
Memory: Dear Program, no problemo, I've put it at address 0x0010fca0, you can use that address in future to get it
Program: Dear Memory, cheers, I'll remember that address!

Later:

Program: Dear Memory, please can you get me a value back, here's the address you gave me earlier: 0x0010fca0
Memory: Too easy mate, the value there is 12345
Program: Great, thanks!

-----------
Moral of the story: Variables in programs are memory addresses.
During compilation the compiler keeps a lookup table of the human names we're using and the memory addresses that the memory manager allocated, so everywhere it comes across the same variable name again it knows the address it was given the first time. Later when the program is run, the human names are irrelevant and the language runtime (e.g. JVM for Java) just uses the addresses.

If you google how compilers work I'm sure you'll find some nice diagrams showing that much clearer than I can say it! Compilers are a fascinating subject and not nearly so difficult as they're sometimes made out Cheesy
Offline cylab

JGO Kernel


Medals: 195



« Reply #2 - Posted 2014-11-14 09:52:35 »

I have to nit-pick here, that the program is not asking the memory, but the operating system to allocate a chunk of memory and gets back the address of that location.

Mathias - I Know What [you] Did Last Summer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline matanui159

JGO Coder


Medals: 11
Projects: 1
Exp: 10-12 months


Aww... So cute...


« Reply #3 - Posted 2014-11-14 12:33:45 »

But that doesnt make sense...
How does the program remember that address? Another memory address? Does that address stay with the compiled code? So if two programs use the same memory address, what happens then?

Is it sad that I still get a fright when the computer beeps at me...
Offline matheus23

JGO Kernel


Medals: 138
Projects: 3


You think about my Avatar right now!


« Reply #4 - Posted 2014-11-14 12:38:52 »

But that doesnt make sense...
How does the program remember that address? Another memory address? Does that address stay with the compiled code? So if two programs use the same memory address, what happens then?

Haha good point Smiley

I'm not entirely sure, but that's how I think it is:
In the program assembly code there is a defined memory adress, for example addres 0x0000A001. Each program assembly is a single process in the operating system. So if the OS is currently processing that program and it request to read/write a value in 0x0000A001, it is actually written in RAM at a specific offset. That offset is different in different processes (= programs).

As I said - I'm not entirely sure about that. But I am sure that each program (= process) has it's own part of RAM. It's the OS's duty to manage those.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Roquen

JGO Kernel


Medals: 518



« Reply #5 - Posted 2014-11-14 12:56:59 »

It depends on what you're talking about.  Say program addresses (part of the code)...it depends on object file format and opcode type.  Some opcodes will be relative offsets.  Others are fixed offsets.  For fixed offsets then the object format is either fixed or relocatable.  If relocatable then the exact addresses are resolved at load time.  Modern OSes and virtually memory (part of the CPU) give a virtual memory space to each process, so each is independent from all the rest...in other words address X in process 0 and address X in process 1 are not the same physical address (exceptions here for shared accesses, but we'll ignore that).

If you're talking about data in a program...then 'pointer' is what you're asking for.
Offline RobinB

JGO Ninja


Medals: 45
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #6 - Posted 2014-11-14 14:06:49 »

Code is just a bunch of adresses requesting eachother Smiley
Its all a huge stack!
Offline richierich
« Reply #7 - Posted 2014-11-14 14:32:39 »

Does that address stay with the compiled code? So if two programs use the same memory address, what happens then?
But I am sure that each program (= process) has it's own part of RAM. It's the OS's duty to manage those.

That's basically it. The OS makes it so that as far as each running program is concerned, it has the whole addressable memory to itself (on Win32 that's 2Gb of "address space").

But in reality there may be many programs running, and indeed the computer may not actually have 2Gb of memory even though it's pretending it does. The OS hides all that - it's called "virtual memory" (http://en.wikipedia.org/wiki/Virtual_memory) and the addresses the program is given are virtual addresses.

Then Java programs are even more complicated because the JVM's another layer of memory management on top (with garbage collection and stuff). Like an onion - there's always another layer underneath Cheesy
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #8 - Posted 2014-11-14 20:49:18 »

(DISCLAIMER: Possibly a lot of inaccurate information below. I'd like to think I have an almost decent idea of how memory works, but I don't know what I don't know. If I said something wrong, please correct me, and please research for yourself before trusting anything I have said)

Depends on whether it's stack or heap allocated.

A stack is just a block of memory, usually one per thread. When a function is called it is responsible for returning the stack to the state it was in at the start of the function. So when something is stack allocated, the compiler knows exactly where each piece of data is going to be relative to the top of the stack. Therefore the opcodes required to access the stack memory are all determined at compile time and aren't actually stored in memory at all (unless you count the opcodes themselves).

The advantages of stack allocation are speed and no garbage collection requirement. When a function exits, all the stack allocations it made are automatically deleted, so any persistent data needs to be copied off the stack to another location (in the case of return values, they usually end up back on the stack). Also, the stack can only be used to store data for which the size is known at compile time. Lots of the time, especially in games, the amount and size of the data cannot be determined until runtime.

This is where heap allocation comes in. The heap is really just a 'heap' of memory. This is memory managed by the system and sort-of 'lent out' to programs. When something is heap allocated, a call is sent to the system asking for a pointer to block of memory of whatever size. If that memory is available, it returns the memory location of the start of that chunk of memory, also know as a pointer. This pointer is just an integer value (on modern machines, 32- or 64-bit depending on the CPU architecture), and so is stored on the stack like any other value (or, stored in the heap, resulting in a pointer to a pointer). This memory can be freely passed around between functions as a pointer on the stack, but it must be explicitly freed (via another system call) or else the computer will eventually run out of memory.

This is where the main problem of manual memory management comes in. You always have to make sure that memory is freed exactly once, and never used after it is freed. However, when you're passing copies of the same pointer all over the place it becomes hard to tell when exactly that should be. Free it too early and you'll most likely get segfaults when you try to access it later. Forget to free it and you get memory leaks.

There are several ways this problem is overcome in modern languages. The most popular is garbage collection, but this comes at a high price. Lots of CPU cycles are used tracking where each piece of data is being used, as well as detecting and responding to cycles (A contains the last pointer to B which contains the last pointer to A, etc. so while neither are really being used, it's not that obvious). Other alternatives include simpler but incomplete forms of garbage collection (eg: reference-counting), or using unique pointers (a single reference to a memory location that automatically frees it when the pointer is freed). These incomplete alternatives still require a bit of manual intervention, but they do make the job a bit easier.

In Java, everything objects are heap allocated. This causes lots of pains with the garbage collector as data that could be easily freed as soon as the method exits instead has to be collected like anything else.

If all this post hasn't scared you away from manual memory management and you have a lot of spare time on your hands, I recommend having a look at Rust. It's a language that has no runtime automatic memory management (and so is fast), but instead enforces that you don't do anything stupid at compile time (so no segfaults or memory leaks). If you're interested, maybe read this reddit comment about a Java/Scala developer's experience with Rust.
Quote
...
Even if you work with a high-level language, after Rust you do think more about who owns what and how the data should be passed around.
...

Offline Slyth2727
« Reply #9 - Posted 2014-11-14 21:12:08 »

Moral of the story: Variables in programs are memory addresses.

In Java*
In C++/C (and maybe some other languages) you have to tell the program what's a pointer and what isn't. By default it isn't. In Java technically everything is a pointer.

Am I right?

Edit: Hey, 700th post.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #10 - Posted 2014-11-14 21:27:57 »

In Java, everything is heap allocated.

Just to be clear, Objects are heap allocated. Primitives (like ints, doubles and pointers) are (since their size is known) allocated on the stack.

Computerphile has a video on stacks and why they are fundamental to how we do computation: https://www.youtube.com/watch?v=7ha78yWRDlE
If you liked that, you should go and watch as much of their other stuff as you have time for. It's good stuff.
Offline pitbuller
« Reply #11 - Posted 2014-11-14 21:30:48 »

In Java, everything is heap allocated.

Just to be clear, Objects are heap allocated. Primitives (like ints, doubles and pointers) are (since their size is known) allocated on the stack.

Computerphile has a video on stacks and why they are fundamental to how we do computation: https://www.youtube.com/watch?v=7ha78yWRDlE
If you liked that, you should go and watch as much of their other stuff as you have time for. It's good stuff.

Nothing says that objects are heap allocated. You just don't have the control. Because of this JVM can optimize allocations away if its like.
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #12 - Posted 2014-11-14 21:35:17 »

AFAIK, the escape analysis is there and it is possible to determine whether an object could be stack allocated, but I am yet to see a JVM that actually does it.

Offline The Lion King
« Reply #13 - Posted 2014-11-14 21:52:06 »

I would recommend picking up a simple educational assembly language. It will help you understand these things way better. But yes, when you request to allocate memory from the OS it simply returns you a pointer to the first block of memory you allocated. You keep track of this block in your program. (if you have an OS, if not or if it is OS running code then you just use whatever memory locations you please, and you program your program to not cause memory over runs, etc.)

"You have to want it more than you want to breath, then you will be successful"
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #14 - Posted 2014-11-14 22:09:24 »

Nothing says that objects are heap allocated. You just don't have the control. Because of this JVM can optimize allocations away if its like.

True, although it doesn't seem to happen much and you definitely can't count on it. But I will concede that you are technically correct.
Offline Nate

« JGO Bitwise Duke »


Medals: 167
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #15 - Posted 2014-11-15 01:11:13 »

Try this, IMO it's written in a way that is easily understood:
http://math.hws.edu/javanotes/c1/s1.html
Read the whole thing, it's very good:
http://math.hws.edu/javanotes/
Start at chapter 1 of course.

Offline Roquen

JGO Kernel


Medals: 518



« Reply #16 - Posted 2014-11-15 10:49:23 »

A heap is purely user-side code.  It's a rough classification of a type of data-structure for managing memory.  Specifically there be a boundary tag (or similar) associated with each chunk that the heap is aware of.  All GCs are heap based except semi-space.  Almost all memory managers provided by a language runtimes are heaps.  Neither the OS nor CPUs care about heaps.
Offline nsigma
« Reply #17 - Posted 2014-11-15 13:04:31 »

AFAIK, the escape analysis is there and it is possible to determine whether an object could be stack allocated, but I am yet to see a JVM that actually does it.

Am I missing something?  I was under the impression that this was enabled by default since 2009!  persecutioncomplex  OK, technically this is scalar replacement not stack allocation, but in this context (not user defined) what would be the difference?  What benefits are missing?

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline DrZoidberg

JGO Coder


Medals: 21



« Reply #18 - Posted 2014-11-15 23:54:37 »

If you want to truly understand how this stuff works you need to learn assembler and write some (small simple) programs in it. Looking at C and what kind of assembler code a C compiler produces helps too.
I recommend you work through Computer Science 61C
https://www.youtube.com/watch?v=flQuXQQaYE8&t=0s&list=PL-XXv-cvA_iDHtKXLFJbDG-i6L9oDr5X9
It explains everything.
Offline matanui159

JGO Coder


Medals: 11
Projects: 1
Exp: 10-12 months


Aww... So cute...


« Reply #19 - Posted 2014-11-15 23:56:19 »

So I'm guessing it is similar to how windows works... When you draw at 0,0 it doesn't actually draw at the actual 0,0 but it draws at 0,0 on the window assigned to the program...

In the same way the memory address 0 isn't at 0 but it is at 0 on the assigned memory group...

Am I right? (Or am I right [aw yeeeaaah Cool ])

Also, I tried learning C++ but I got completely stumped and after a few weeks of complete anoying pain I googled why C++ sucks... It was fun... I guess I am just used to Java

Is it sad that I still get a fright when the computer beeps at me...
Offline HeroesGraveDev

JGO Kernel


Medals: 382
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #20 - Posted 2014-11-16 00:09:06 »

There's a difference between programming C++ and programming Java in C++.

A new language is not just a new syntax. There's lots of new patterns to learn, and some that don't work in one language work really well in another, or vice versa.

Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #21 - Posted 2014-11-16 00:09:35 »

In the same way the memory address 0 isn't at 0 but it is at 0 on the assigned memory group...

Pretty much, the more concise way to think about it is as an offset:

1  
2  
3  
4  
// array is located at some address, but we don't care,
// we use addresses relative to the offset of the array:
int[] array = new int[10];
int a = array[4]; // we fetched the data at {array offset} + {sizeOf int} * 4


Individual variable offsets are also relative to the offset of the program they are contained in, which is in turn contained in the "virtual address space" created by the OS.
It's offsets all the way down...
Offline The Lion King
« Reply #22 - Posted 2014-11-16 00:34:34 »

Learn C NOT C++ if you wanna learn about memory, there is too much noise in C++ that keeps you from learning the systems programming part of it. In fact you might even wanna pick up a simple assembly language/machine language for the sake of learning how all this works without all the abstraction, it will help you visualize how programs work (Don't try picking up x86 first, there are other asm languages made with the sole intention of teaching asm)

"You have to want it more than you want to breath, then you will be successful"
Offline matheus23

JGO Kernel


Medals: 138
Projects: 3


You think about my Avatar right now!


« Reply #23 - Posted 2014-11-16 10:46:46 »

Just try out Assembly language. It helps understanding what happens in the lowest programmable layer. I found assembly language easy to understand. It's just really hard to write big bug-free programs with it, but the for the sake of understanding, I'd recommend. Smiley

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline richierich
« Reply #24 - Posted 2014-11-16 12:49:15 »

Just try out Assembly language. It helps understanding what happens in the lowest programmable layer.

Isaac Asimov wrote a famous short story on this general theme in the early days of computers called "The Feeling of Power". It's quite short and well worth a read if you're having a lazy Sunday ... here's the text in a web page: http://downlode.org/Etext/power.html

The moment you "get" assembler and realize all other languages, operating systems and all the rest, come down to the same simple stuff, nothing about software will ever be scary again Cheesy
Offline ra4king

JGO Kernel


Medals: 508
Projects: 3
Exp: 5 years


I'm the King!


« Reply #25 - Posted 2014-11-16 20:57:46 »

The best way to learn assembly is to learn the LC3 assembly. Google it, learn it, have fun with it.

Offline The Lion King
« Reply #26 - Posted 2014-11-16 21:27:53 »

The best way to learn assembly is to learn the LC3 assembly. Google it, learn it, have fun with it.

LOL do you use: Introduction to Computing Systems: From bits & gates to C & beyond? I learned LC-3 but found there is very, very little on the subject except that one book. Thats the only reason I can't recommend LC-3 unless you also decide to buy that book (which isn't a bad buy it is actually very informative book)

"You have to want it more than you want to breath, then you will be successful"
Offline ra4king

JGO Kernel


Medals: 508
Projects: 3
Exp: 5 years


I'm the King!


« Reply #27 - Posted 2014-11-16 21:32:49 »

Enjoy: https://www.dropbox.com/s/n9s12aywnmtgn19/Introduction_to_computing_systems.pdf?dl=0

It's a really great book. The language is easy to read and the subject is actually pretty fun.

Offline matanui159

JGO Coder


Medals: 11
Projects: 1
Exp: 10-12 months


Aww... So cute...


« Reply #28 - Posted 2014-11-17 02:24:05 »

I don't really want to learn any of those languages...
My chosen language is Java and I am not changing...
I just wanted to know the answer to a question that was on my mind...
Btw, thx for answering...

Is it sad that I still get a fright when the computer beeps at me...
Offline Slyth2727
« Reply #29 - Posted 2014-11-17 03:12:14 »

My chosen language is Java and I am not changing...

No. One does not simply use one language and one language only. If you really want to learn how to program, become multilingual.
Pages: [1] 2
  ignore  |  Print  
 
 

 
Riven (34 views)
2019-09-04 15:33:17

hadezbladez (3979 views)
2018-11-16 13:46:03

hadezbladez (1444 views)
2018-11-16 13:41:33

hadezbladez (3986 views)
2018-11-16 13:35:35

hadezbladez (769 views)
2018-11-16 13:32:03

EgonOlsen (4085 views)
2018-06-10 19:43:48

EgonOlsen (4664 views)
2018-06-10 19:43:44

EgonOlsen (2753 views)
2018-06-10 19:43:20

DesertCoockie (3647 views)
2018-05-13 18:23:11

nelsongames (3849 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!