Int i=10;-->where will the value of i is stored in memory or registers??

[anu@09]

if its store in memory,in which segment does it store??

 

[Kewlx25]

The compiler will typically optimize to store "i" in a register. You can also give a compiler hint by using "register int i".

You need to be careful about this if doing multi-threading because changes to "i" may not get pushed out to memory for another register to read, assuming you share the memory location some how.

When it's stored "in memory", it's stored on the stack.

 

[blakwidowrsa]

The compiler will typically optimize to store "i" in a register. You can also give a compiler hint by using "register int i".

You need to be careful about this if doing multi-threading because changes to "i" may not get pushed out to memory for another register to read, assuming you share the memory location some how.

When it's stored "in memory", it's stored on the stack.

Actually, the actual value of the data in memory is in the HEAP, and the pointer pointing to the data is in the STACK.

Where will the value of i is stored in memory or registers??

Int i(variable)=10(value);
or
Int i(register)=10(memory);
or
Int i(Stack)=10(Heap);

So the VALUE is stored in Memory, and is located with a pointer in the stack, pointing to that memory.

 

[Kewlx25]

Actually, the actual value of the data in memory is in the HEAP, and the pointer pointing to the data is in the STACK.

Where will the value of i is stored in memory or registers??

Int i(variable)=10(value);
or
Int i(register)=10(memory);
or
Int i(Stack)=10(Heap);

So the VALUE is stored in Memory, and is located with a pointer in the stack, pointing to that memory.

You must have a horrible compiler that allocated value types in the heap and uses pointers to reference them.

Unless "int i" is declared in a struct/class, it is just about guaranteed to be on the stack. Actually, it may be guaranteed to be on the stack, not quite 100% sure of all cases.

Another way to look at it is that *if* a pointer was involved, it would require 2 operations to access Int i. First the CPU has to load the pointer, then it needs to access the memory location. Five things bad about this.
1) On a 32bit machine an Int is typically 32 bits and so are the pointers. This means you doubled the amount of memory requires.
2) On a 64bit machine an Int is typically 32 bits but the pointers are 64bits. So a 64bit pointer to a 32bit value is tripling memory usage.
3) Memory on the heap can get fragmented and allocating un-organized(not in a struct/class) values on the heap is a horrible thing to do.
4) This introduces random memory access into the heap, which is bad.
5) Because of the above, cache misses would be horrible as the CPU stores data 64bytes at a time. Pointers to randomly allocated value types on the heap would cause the CPU to be swapping in and out 64bytes just to load a 32bit(4byte) in, quite often.

 

[blakwidowrsa]

Actually, the actual value of the data in memory is in the HEAP, and the pointer pointing to the data is in the STACK.

Where will the value of i is stored in memory or registers??

Int i(variable)=10(value);
or
Int i(register)=10(memory);
or
Int i(Stack)=10(Heap);

So the VALUE is stored in Memory, and is located with a pointer in the stack, pointing to that memory.

You must have a horrible compiler that allocated value types in the heap and uses pointers to reference them.

Unless "int i" is declared in a struct/class, it is just about guaranteed to be on the stack. Actually, it may be guaranteed to be on the stack, not quite 100% sure of all cases.

Another way to look at it is that *if* a pointer was involved, it would require 2 operations to access Int i. First the CPU has to load the pointer, then it needs to access the memory location. Five things bad about this.
1) On a 32bit machine an Int is typically 32 bits and so are the pointers. This means you doubled the amount of memory requires.
2) On a 64bit machine an Int is typically 32 bits but the pointers are 64bits. So a 64bit pointer to a 32bit value is tripling memory usage.
3) Memory on the heap can get fragmented and allocating un-organized(not in a struct/class) values on the heap is a horrible thing to do.
4) This introduces random memory access into the heap, which is bad.
5) Because of the above, cache misses would be horrible as the CPU stores data 64bytes at a time. Pointers to randomly allocated value types on the heap would cause the CPU to be swapping in and out 64bytes just to load a 32bit(4byte) in, quite often.

OK, I came from a C++ perspective:

The stack is the memory set aside as scratch space for a thread of execution. When a function is called, a block is reserved on the top of the stack for local variables and some bookkeeping data. When that function returns, the block becomes unused and can be used the next time a function is called. The stack is always reserved in a LIFO order; the most recently reserved block is always the next block to be freed. This makes it really simple to keep track of the stack; freeing a block from the stack is nothing more than adjusting one pointer.

The heap is memory set aside for dynamic allocation. Unlike the stack, there's no enforced pattern to the allocation and deallocation of blocks from the heap; you can allocate a block at any time and free it at any time. This makes it much more complex to keep track of which parts of the heap are allocated or free at any given time; there are many custom heap allocators available to tune heap performance for different usage patterns.

Each thread gets a stack, while there's typically only one heap for the application (although it isn't uncommon to have multiple heaps for different types of allocation).

To answer your questions directly:


The OS allocates the stack for each system-level thread when the thread is created. Typically the OS is called by the language runtime to allocate the heap for the application.


The stack is attached to a thread, so when the thread exits the stack is reclaimed. The heap is typically allocated at application startup by the runtime, and is reclaimed when the application (technically process) exits.


The size of the stack is set when a thread is created. The size of the heap is set on application startup, but can grow as space is needed (the allocator requests more memory from the operating system).


The stack is faster because the access pattern makes it trivial to allocate and deallocate memory from it (a pointer/integer is simply incremented or decremented), while the heap has much more complex bookkeeping involved in an allocation or free. Also, each byte in the stack tends to be reused very frequently which means it tends to be mapped to the processor's cache, making it very fast.


Stack:
Stored in computer RAM like the heap.
Variables created on the stack will go out of scope and automatically deallocate.
Much faster to allocate in comparison to variables on the heap.
Implemented with an actual stack data structure.
Stores local data, return addresses, used for parameter passing
Can have a stack overflow when too much of the stack is used. (mostly from inifinite (or too much) recursion, very large allocations)
Data created on the stack can be used without pointers.
You would use the stack if you know exactly how much data you need to allocate before compile time and it is not too big.
Usually has a maximum size already determined when your program starts

Heap:
Stored in computer RAM like the stack.
Variables on the heap must be destroyed manually and never fall out of scope. The data is freed with delete, delete[] or free
Slower to allocate in comparison to variables on the stack.
Used on demand to allocate a block of data for use by the program.
Can have fragmentation when there are a lot of allocations and deallocations
In C++ data created on the heap will be pointed to by pointers and allocated with new or malloc
Can have allocation failures if too big of a buffer is requested to be allocated.
You would use the heap if you don't know exactly how much data you will need at runtime or if you need to allocate a lot of data.
Responsible for memory leaks

 

[blakwidowrsa]

Actually, the actual value of the data in memory is in the HEAP, and the pointer pointing to the data is in the STACK.

Where will the value of i is stored in memory or registers??

Int i(variable)=10(value);
or
Int i(register)=10(memory);
or
Int i(Stack)=10(Heap);

So the VALUE is stored in Memory, and is located with a pointer in the stack, pointing to that memory.

You must have a horrible compiler that allocated value types in the heap and uses pointers to reference them.

Unless "int i" is declared in a struct/class, it is just about guaranteed to be on the stack. Actually, it may be guaranteed to be on the stack, not quite 100% sure of all cases.

Another way to look at it is that *if* a pointer was involved, it would require 2 operations to access Int i. First the CPU has to load the pointer, then it needs to access the memory location. Five things bad about this.
1) On a 32bit machine an Int is typically 32 bits and so are the pointers. This means you doubled the amount of memory requires.
2) On a 64bit machine an Int is typically 32 bits but the pointers are 64bits. So a 64bit pointer to a 32bit value is tripling memory usage.
3) Memory on the heap can get fragmented and allocating un-organized(not in a struct/class) values on the heap is a horrible thing to do.
4) This introduces random memory access into the heap, which is bad.
5) Because of the above, cache misses would be horrible as the CPU stores data 64bytes at a time. Pointers to randomly allocated value types on the heap would cause the CPU to be swapping in and out 64bytes just to load a 32bit(4byte) in, quite often.

OK, I came from a C++ perspective:

The stack is the memory set aside as scratch space for a thread of execution. When a function is called, a block is reserved on the top of the stack for local variables and some bookkeeping data. When that function returns, the block becomes unused and can be used the next time a function is called. The stack is always reserved in a LIFO order; the most recently reserved block is always the next block to be freed. This makes it really simple to keep track of the stack; freeing a block from the stack is nothing more than adjusting one pointer.

The heap is memory set aside for dynamic allocation. Unlike the stack, there's no enforced pattern to the allocation and deallocation of blocks from the heap; you can allocate a block at any time and free it at any time. This makes it much more complex to keep track of which parts of the heap are allocated or free at any given time; there are many custom heap allocators available to tune heap performance for different usage patterns.

Each thread gets a stack, while there's typically only one heap for the application (although it isn't uncommon to have multiple heaps for different types of allocation).

To answer your questions directly:


The OS allocates the stack for each system-level thread when the thread is created. Typically the OS is called by the language runtime to allocate the heap for the application.


The stack is attached to a thread, so when the thread exits the stack is reclaimed. The heap is typically allocated at application startup by the runtime, and is reclaimed when the application (technically process) exits.


The size of the stack is set when a thread is created. The size of the heap is set on application startup, but can grow as space is needed (the allocator requests more memory from the operating system).


The stack is faster because the access pattern makes it trivial to allocate and deallocate memory from it (a pointer/integer is simply incremented or decremented), while the heap has much more complex bookkeeping involved in an allocation or free. Also, each byte in the stack tends to be reused very frequently which means it tends to be mapped to the processor's cache, making it very fast.


Stack:
Stored in computer RAM like the heap.
Variables created on the stack will go out of scope and automatically deallocate.
Much faster to allocate in comparison to variables on the heap.
Implemented with an actual stack data structure.
Stores local data, return addresses, used for parameter passing
Can have a stack overflow when too much of the stack is used. (mostly from inifinite (or too much) recursion, very large allocations)
Data created on the stack can be used without pointers.
You would use the stack if you know exactly how much data you need to allocate before compile time and it is not too big.
Usually has a maximum size already determined when your program starts

Heap:
Stored in computer RAM like the stack.
Variables on the heap must be destroyed manually and never fall out of scope. The data is freed with delete, delete[] or free
Slower to allocate in comparison to variables on the stack.
Used on demand to allocate a block of data for use by the program.
Can have fragmentation when there are a lot of allocations and deallocations
In C++ data created on the heap will be pointed to by pointers and allocated with new or malloc
Can have allocation failures if too big of a buffer is requested to be allocated.
You would use the heap if you don't know exactly how much data you will need at runtime or if you need to allocate a lot of data.
Responsible for memory leaks