Heap maintenance and wordsize

[rd]

Hi i'm uncertain about foll. things. Thanks in advance for any help to
get me out of this..

Each process, with their own stack, will they have their own heap or is it global one(common for all process)? if local,
Any Limit on heap size like stack?

if global,
what if u dont free()?
How heap is initialized and maintained?? (any reference/link for
heap/stack maintenace)

WORDSIZE:
what is the relation between sizeof(int) in C and wordsize of an OS?(will it be 4 bytes, if u run gcc now in older OSs like WIN95 (16
bit)..)
I dont understand the context clearly, and i myself build lot of ambiguous things, when it is said 32 bit os, 32 bit compiler, wordsize,... help me to get out of it.

MALLOC:

(this one lasted for 40 mins..) Consider following sample..

char *arr=malloc(50) ;

it is not guarenteed that memory for 'arr' will be contigous.. and
when you use

for(i=0;i<50;i+ +) {.. arr[i++]; ... }

how the indexing will be actually reflected in physical memory..? we
just increment like arr+25,arr+26,. . and what if memory is not
contigous?

Thanks
Deva

[Malcolm]

"rd" <ma*********@gm ail.com> wrote

Each process, with their own stack, will they have their own heap or is
it >>>global one(common for all process)? if local,

Any Limit on heap size like stack?

if global,
what if u dont free()?

Depends on your memory manager incorporated into the OS and how effectively
it is used by a compiler. A decent system will have a pool of memory on
which all programs can draw and return on demand, but prevent any one
program from hogging the whole lot. Bad systems often give programs memory
on demand, but then don't let them return it until they terminate.
A terrible system may tie up unfreed memory until reboot. You've got to
either be very unlucky or be using a hacked together OS for a small system
for this to happen.
How heap is initialized and maintained?? (any reference/link for
heap/stack maintenace)
Totally system dependent. Normally the OS keeps track of "pages" which it
gives to each program. The malloc() routine then stitches those pages
together to provide a nice flat memory space for the caller.
char *arr=malloc(50) ;

it is not guarenteed that memory for 'arr' will be contigous.. and
when you use

for(i=0;i<50;i+ +) {.. arr[i++]; ... }

how the indexing will be actually reflected in physical memory..? we
just increment like arr+25,arr+26,. . and what if memory is not
contigous?

Normally there would be hardware support for a lookup system. In the olden
days the bits in a pointer usually reflected the physical signals sent on
the pins to the memory chip. Nowadays they will usually go through several
layers of indirection, so arr[25] and arr[26] might be located on entirely
different chips, but the pointer values are contiguous.

[pete]

rd wrote:

char *arr=malloc(50) ;

it is not guarenteed that memory for 'arr' will be contigous.. and
when you use
It's guaranteed on the abstract machine
and that's as guaranteed as anything gets in C.
for(i=0;i<50;i+ +) {.. arr[i++]; ... }

how the indexing will be actually reflected in physical memory..?

In whatever way it takes to prevent a C program
form being able to determine noncontiguity.

--
pete

[SM Ryan]

# >>Each process, with their own stack, will they have their own heap or is it global one(common for all process)?
# if local,
# Any Limit on heap size like stack?
#
# if global,
# what if u dont free()?

Alot depends on what a 'process' is. On something like Unix, each process
has its own address space that cannot be easily modified by any other process.
On something Macintosh System 7 processes clobberring other processes's
memory is a frequent problem. So this depends on the underlying system and
cannot be answerred definitively.

There is some limit to heap size because machines have finite address space
and finite real memory and finite disc space. How much of those fundamental
limitations you can exploit depends on your system.

Resource scavenging on process exit depends on the system: some do,
some don't.

# How heap is initialized and maintained?? (any reference/link for
# heap/stack maintenace)

If you use the stdlib.h functions like malloc and free, the heap is
automagically initialised and maintained for you. Pay no attention to
the library behind the curtain.

# WORDSIZE:
#
# >> what is the relation between sizeof(int) in C and wordsize of an
# OS?(will it be 4 bytes, if u run gcc now in older OSs like WIN95 (16
# bit)..)

Usually they are the same. Whether they are two bytes or four or eight
or something else varies system by system. The situation is confusing
because the computer world is in flux between 32 and 64 bit words
and 8 and 16 bit characters.

# MALLOC:
#
#
# >> (this one lasted for 40 mins..) Consider following sample..
#
# char *arr=malloc(50) ;
#
# it is not guarenteed that memory for 'arr' will be contigous.. and
# when you use

The addresses you use are consecutive. Whether that is mapped into
noncontiguous physical addresses somewhere underneath is not the concern
of the C program; any such mapping must be invisible to your code such
that

# for(i=0;i<50;i+ +) {.. arr[i++]; ... }

works the same on all platforms.

If you do something like
typedef struct {char a,b,c;} abc;
abc *arr = malloc(50*sizeo f(abc));
arr might be allocated 150 or 200 (or elsewise) bytes. The compiler is
allowed to pad out the struct to a more convenient boundary, perhaps
adding one more invisible of char. Each array element is at consecutive
indexes, arr[0], arr[1], arr[2], ..., arr[49], but doesn't mean all
150 chars are contiguous.

That means if you want do something like zeroing out the array, you
should use sizeof
memset(arr,0,50 *sizeof(abc))
instead of trying to outguess the compiler
memset(arr,0,15 0)

--
SM Ryan http://www.rawbw.com/~wyrmwif/
The whole world's against us.

[Chris Croughton]

On Sat, 18 Jun 2005 10:14:53 GMT, pete
<pf*****@mindsp ring.com> wrote:

rd wrote:

char *arr=malloc(50) ;

it is not guarenteed that memory for 'arr' will be contigous.. and
when you use

It's guaranteed on the abstract machine
and that's as guaranteed as anything gets in C.

It depends what you mean by 'memory'. The C standard gauarantees that a
C program can access the memory as though it were contiguous, but since
it describes an "abstract machine" it doesn't say anything about where
that memory 'really' is (it could be split over adjacent -r separated
tracks on a drum, for instance, or across several delay lines -- or on
machines separated by thousands of miles).

for(i=0;i<50;i+ +) {.. arr[i++]; ... }

how the indexing will be actually reflected in physical memory..?

In whatever way it takes to prevent a C program
form being able to determine noncontiguity.

There is no way that a C program can know where the 'physical' memory is
'actually' located. Or whether it is even still there when it isn't
being accessed. All it knows is that as far as it is concerned an
allocated area of memory behaves as if it is contiguous.

(In some operating systems there are of course ways to 'lock' logical
memory to physical memory, but those are off-topic for c.l.c as they are
outside te standard.)

Chris C