stack and a heap

[Guest]

what is the difference between a heap and a stack?

 

[Terry Burns]

They are both memory which is used to store objects. The stack by default
only stores Value types like Struct and Integers, whereas the Heap is used
to allocate memory for reference types.

There are numerous articles on the net about this. Try googling.

 

[Jon Skeet [C# MVP]]

They are both memory which is used to store objects. The stack by default
only stores Value types like Struct and Integers, whereas the Heap is used
to allocate memory for reference types.

That's an oversimplification, unfortunately. The stack is also used to
store references (rather than the objects themselves), and all types
can end up on the heap as part of other objects.

See http://www.pobox.com/~skeet/csharp/memory.html

Note that this doesn't explain the difference between the heap and the
stack, just what goes where.

 

[Willy Denoyette [MVP]]

what is the difference between a heap and a stack?

A stack is a chunk of process memory, that's being used to store local
variables, function return addresses, pointers to next stack frame and
things like that. The stack never holds instances of reference types, when a
local variable refers to a reference type, then the value of the variable
holds a reference to a GC heap allocated object instance, however, when a
local variable refers to a value type, then the value of the type is stored
inline with that variable. Each thread in the process has his own private
stack space, allocated at thread creation time with a fixed maximum size
(default 1MB).
A "StackOverflow" exception will get thrown whenever the stack gets full.
A heap is chunk of process memory that's being created/managed by the OS on
request of the executing program code. The managed heap or GC heap is just
another heap that's being created/managed by the OS on request of the CLR.
The GC heap is a private store managed by the CLR and only used to store
managed objects (instances of reference types or boxed value types). The
size of the GC heap is variable, and is only restricted by the amount of
free virtual address space in the process. A "MemoryOverflow" gets thrown
whenever the available virtual address space is exhausted.

Willy.

 

[Terry Burns]

Yes, I know, sometimes when you know something implicitly, you forget to
state it, thanks for correcting my text.

 

[Gino Cerone]

When an application is opened Windows allocates the full 32 bit address
space (4 gigs) of memory. (this is theoretical and Windows memory manager
maps from the actual memory to the 32 bit memory space) It sub-divides this
into two parts, the Stack and Heap. The stack holds the declared named
varibles. In the case of a primative data type like 'byte' it holds the
value,

byte mybyte;
mybyte = 125;

In the case of instantiating a class, the declared name varible is writen to
the stack. The instaniated Object in writen to the Heap. The value of the
varible in the stack holds the address space of the Object in the Heap.

sqlconnection myconnection; (declares the varible myconnection of type
sqlconnection in the stack. If you tried to use myconnection
now you would get a null
reference error because there isn't a memory address in the value yet.)

myconnection = new sqlconnection; (this line instantiates the class
'sqlconnection' into an Object in the Heap, and enters the address
of the Object in
the value for myconnection. myconnection becomes the pointer that references
the Object
'sqlconnection' in the Heap.)

 

[Willy Denoyette [MVP]]

When an application is opened Windows allocates the full 32 bit address
space (4 gigs) of memory. (this is theoretical and Windows memory manager
maps from the actual memory to the 32 bit memory space) It sub-divides
this
into two parts, the Stack and Heap. The stack holds the declared named
varibles. In the case of a primative data type like 'byte' it holds the
value,

byte mybyte;
mybyte = 125;

In the case of instantiating a class, the declared name varible is writen
to
the stack. The instaniated Object in writen to the Heap. The value of the
varible in the stack holds the address space of the Object in the Heap.

sqlconnection myconnection; (declares the varible myconnection of type
sqlconnection in the stack. If you tried to use myconnection
now you would get a null
reference error because there isn't a memory address in the value yet.)

myconnection = new sqlconnection; (this line instantiates the class
'sqlconnection' into an Object in the Heap, and enters the address
of the Object in
the value for myconnection. myconnection becomes the pointer that
references
the Object
'sqlconnection' in the Heap.)

Sorry, but you present a very simplistic view of the real process memory
space and you got it wrong on several points.
1. The full 32 bit address space is not allocated as user process space,
only a maximum of 2GB or 3GB (using /3GB RAM tuning switch in boot.ini) can
ever be reserved (and possibly committed).
2. This space is not sub-divided into a stack and a heap, there is stack
space allocated per thread created and there is heap space. When the OS
creates a process it always starts with a single thread so your process
always start with a single stack (default size: 4KB committed, 1MB reserved
space).
The default sizes of heap and stack space is determined by:
- the built process - managed code generators generate defaults (see later),
using unmanaged code build tools (like link.exe) one can specify other
values for both heap and stack.
- the values assigned by tools like editbin....
The default sizes for ".NET" processes is:
for the heap 4KB committed and 1MB reserved, extra space can (and will)
be requested by the process at run time.
for the stack 4KB committed and 1MB reserved, the stack can never grow
beyond the reserved maximum.

3. The stack only holds local variables, not all "the declared named
variables".
4. Primitive types (as all value types) are only stack allocated when
declared local (they have function scope), instance variables are GC heap
allocated. Note that locals can also be register allocated!

5. This:

sqlconnection myconnection; (declares the varible myconnection of type
sqlconnection in the stack. If you tried to use myconnection
now you would get a null
reference error because there isn't a memory address in the value yet.)

is not completely true, the compiler will not allow you to use an
uninitialized local variable. If he would allow it, the variable could hold
any possible value that was left on the stack at the location of the
variable.

Willy.

 

[Gino Cerone]

The information that I wrote was abstracted from this link.
http://www.softec.uni-duisburg-essen.de/C15/(C) C und das NET-Framew
ork%20(v/Document%20Library/CSharp_06_MemoryManagement.pdf
Which was writen by Dr. Stefan Eicker, who holds a PHD in computer science,
and is a University professor and head of software engineering at the
University of Essen Germany. So it is ( according to you) Dr. Stefan Eicker
who is simplistic and wrong.

 

[Terry Burns]

This takes me back to the playground

8=}

--
Terry Burns
http://TrainingOn.net

 

[Willy Denoyette [MVP]]

The information that I wrote was abstracted from this link.
http://www.softec.uni-duisburg-essen.de/C15/(C) C und das NET-Framew
ork%20(v/Document%20Library/CSharp_06_MemoryManagement.pdf
Which was writen by Dr. Stefan Eicker, who holds a PHD in computer
science,
and is a University professor and head of software engineering at the
University of Essen Germany. So it is ( according to you) Dr. Stefan
Eicker
who is simplistic and wrong.

No, HE's not wrong and/or simplistic because:
1. He doesn't say (see point 2, 3 in my reply) what YOU originaly posted,
except for one point (see point 1 in my reply) where HE is wrong too.
2. you are refering to "presentations" material which is not intended as
reading material, I never said his "presentations" were simplistic, how
could I, I never attended one. No, I said YOUR description is a bit
simplistic (see point 2, 3).

Next time when refering to anothers material, please add a quote in your
posting, Dr. Stefan Eicker deserves it, and you won't need to refer to it
after the facts.

Willy.