[SOLVED] Processes ,the stack and static memory: How can the stack be considered static?

theKbStockpiler · 05-19-2010, 04:29 PM

I'm reading a tutorial that says that processes store variable data in the same space as code. It also does not exclude the stack from static memory. How can the stack change and be part of static memory? Is the size of the stack accounted for when it is compiled?

Thanks in advance
Stating that (no offense is intended) is not required for this thread.
The source of confusion is located at:
http://arjay.bc.ca/Modula-2/Text/Ch12/Ch12.4.html

johnsfine · 05-19-2010, 05:09 PM

Are you confused by just the following section or by something more?

Quote:

observe that what has been said so far about static memory for program variable also applies to procedures in exactly the same way. Just as whenever a program is run static memory is set aside, so also whenever a procedure is entered, memory must be set aside for its parameters and variables. (The code for the procedure has memory within the block of memory for the code of the entire program.) When the procedure is running, the memory it employs for its variables can be regarded as static. Indeed, the relative positions of the memory for each variable with respect to the start of this memory block is all worked out by the compiler ahead of time so that assignments to such variables may be properly coded.

That certainly introduces an important way in which stack data is similar to static data and both are dissimilar to dynamic data.

But you seem to be upset about some greater level of equivalence between stack and static than I've noticed in the page.

Quote:

Is the size of the stack accounted for when it is compiled?

In a single threaded Windows program, the size and location of the stack are in the executable (normally determined at link time). In Linux the size of the first thread's stack is not determined until load time.

theKbStockpiler · 05-19-2010, 05:46 PM

Quote:

Originally Posted by johnsfine

Are you confused by just the following section or by something more?

That certainly introduces an important way in which stack data is similar to static data and both are dissimilar to dynamic data.

But you seem to be upset about some greater level of equivalence between stack and static than I've noticed in the page.

In a single threaded Windows program, the size and location of the stack are in the executable (normally determined at link time). In Linux the size of the first thread's stack is not determined until load time.

I'm pretty sure you understand.

I think what you are saying in the windows example is that the size and address are included in the executive but data is located some where else? Its that correct? Static memory would then change but it's size and location is stated in the code?

Sergei Steshenko · 05-19-2010, 06:31 PM

Quote:

Originally Posted by theKbStockpiler

I'm reading a tutorial that says that processes store variable data in the same space as code. It also does not exclude the stack from static memory. How can the stack change and be part of static memory? Is the size of the stack accounted for when it is compiled?
...

What is the problem with stack being static or, rather, what are your definitions of static and dynamic in this context ?

paulsm4 · 05-19-2010, 06:32 PM

Remember - the article is about Modula 2. So the some of the details may or may not be applicable to "stacks" in general!

But the *main* point I believe he's trying to make in the article has to do with the concept of "activation records":

Quote:

The memory assigned to a procedure for its parameters and variables when it is invoked is called an activation record for the procedure.
...

The area of memory into which procedure activation records are dynamically and automatically placed is called the stack.

This is in contrast to "Dynamic variables":

Quote:

Dynamic variables are those that can have the space allocated to them as needed at some point during the execution of a program or procedure and that can also be disposed of and have their space given back to the system by the program.
...
The region of memory above the stack and in which program-controlled dynamic allocation and deallocation of memory can take place is called the heap.

'Hope that helps .. PSM

theKbStockpiler · 05-19-2010, 08:52 PM

Quote:

Originally Posted by Sergei Steshenko

What is the problem with stack being static or, rather, what are your definitions of static and dynamic in this context ?

johnsfine I believe deciphered the "The code for the procedure has memory within the block of memory for the code of the entire program." The code holds the size and relative address but not the actual data.

After I read the tutorial another six times I discovers that;

In addition It actually looks like the author is trying to convey 3 types of memory.

1 Static

2,Automatic Dynamics

3.Dynamic

It's my mistake that they are just describing a black or white Static or Dynamic memory types. They are not.

I'm reading about program memories to fill in some blank spots of my general understanding of programming. It's seams common for an author to explain concepts with other concepts that are outside the immediate scope of information. Every time I read a book on C I get side tracked. Thanks for asking

Sergei Steshenko · 05-19-2010, 09:06 PM

Quote:

Originally Posted by theKbStockpiler

johnsfine I believe deciphered the "The code for the procedure has memory within the block of memory for the code of the entire program." The code holds the size and relative address but not the actual data.

After I read the tutorial another six times I discovers that;

In addition It actually looks like the author is trying to convey 3 types of memory.

1 Static

2,Automatic Dynamics

3.Dynamic

It's my mistake that they are just describing a black or white Static or Dynamic memory types. They are not.

I'm reading about program memories to fill in some blank spots of my general understanding of programming. It's seams common for an author to explain concepts with other concepts that are outside the immediate scope of information. Every time I read a book on C I get side tracked. Thanks for asking

If we are talking about "C" and its dynamic (auto) variables, they are dynamic in a sense their address is not known at compilation and even link time. I.e. their address is known at the moment a function containing them is called. And the called function may be called after (many) other functions are called, and this (how many other functions have been called before) can change during the execution.

So, the dynamic/auto variables have no fixed address, and in this sense their address is dynamic.

Now, it happens so that the piece of memory where these dynamic/auto variables reside is called stack. But by itself this piece of memory may quite be static in a sense its start address and size is known beforehand.

For that matter, the address of the area where global/static variables reside may be dynamic - it depends on the way the OS deals with it and how addressing in general is implemented in a given CPU. I.e. a CPU may have so called base registers and addressing may be implemented as relative to those base registers.

Furthermore, in, say, x86 it is all even further moot because there are segment registers to add to the confusion.

wje_lq · 05-19-2010, 11:26 PM

The actual size of the stack usually doesn't matter, because the stack grows "automatically" (that is, the operating system responds by making the stack grow and restarting the instruction which caused the discovery that the stack needed to grow), up to a certain limit. What is that limit?

The limit is determined later than compile time, and earlier than the time that the program is loaded. The limit is determined by the shell that runs the program. You can ask the shell what that limit is, and change that limit, with the ulimit command. And your C program can examine and change that limit while it's running with getrlimit() and setrlimit().

To illustrate, here is a shell script which compiles a C program and runs it. The program causes the stack segment to grow to its limit through infinite recursion. Each time the actual size of the segment changes, the recursion count and the appropriate line of /proc/self/maps is listed.

The shell script actually runs the program twice. The second time, the program doubles the stack size limit at the beginning.

The output is quite lengthy, so you might want to redirect it to a file and examine that file with less.

Before running this, you might want to

Code:

less /proc/self/maps

Anyway, here's the shell script.

Code:

rm -f 1; cat <<EOD >1.c; gcc -Wall -Werror 1.c -o 1; ./1; ./1 x
/*--------------------------------------------------------------------------*/
#include <sys/resource.h>
#include <sys/time.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
/*--------------------------------------------------------------------------*/
#define MAP_PATH "/proc/self/maps"
char  old_line[4096];
/*--------------------------------------------------------------------------*/
void measure(int count_dracula)
{
  char  new_line[4096];

  FILE *map_phyle;

  map_phyle=fopen(MAP_PATH,"r");

  if(map_phyle==NULL)
  {
    perror("opening maps file");

    exit(1);
  }

  while(fgets(new_line,sizeof(new_line),map_phyle))
  {
    if(strstr(new_line,"[stack]"))
    {
      break;   /* <--------- */
    }
  }

  fclose(map_phyle);

  if(strcmp(old_line,new_line))
  {
    strcpy(old_line,new_line);

    printf("%d %s",count_dracula,new_line);

    fflush(stdout);
  }

} /* measure() */
/*--------------------------------------------------------------------------*/
void crank_her_up(int depth)
{
  measure(depth);
  depth++;
  crank_her_up(depth);

} /* crank_her_up() */
/*--------------------------------------------------------------------------*/
int main(int argc,
         char **argv
        )
{
  struct rlimit our_limit;

  if(getrlimit(RLIMIT_STACK,&our_limit))
  {
    perror("getrlimit");

    exit(1);
  }
  if(argc>1)
  {
    our_limit.rlim_cur*=2;
    if(setrlimit(RLIMIT_STACK,&our_limit))
    {
      perror("getrlimit");

      exit(1);
    }
  }
  printf("stack limit is %ld soft, %ld hard\n",our_limit.rlim_cur,our_limit.rlim_max);
  crank_her_up(0);
  return 0;

} /* main() */
EOD

johnsfine · 05-20-2010, 09:01 AM

Quote:

Originally Posted by wje_lq

The actual size of the stack usually doesn't matter, because the stack grows "automatically" (that is, the operating system responds by making the stack grow and restarting the instruction which caused the discovery that the stack needed to grow), up to a certain limit.

That description differs only in terminology, not meaning, from what I said.

There are many situations in which the kernel delays (and usually avoids) allocating physical memory that appears to the program to have been allocated. When discussing behavior as seen from inside the program, one normally ignores those optimizations and pretends the memory is there.

For example, if your C program allocates a giant static uninitialized array, the loader will seem to fill that space with zeroes. Actually it won't. That memory won't even exist when the loader is done. Each page of that memory will become zero filled the first time it is read and/or it will be allocated and zero filled the first time it is written. But if a C programmer wants to know the initial contents of a giant uninitialized static array, the answer is just "zero filled", not the above complicated way of saying zero filled if necessary later.

From the viewpoint inside a process, the size allocated to the first thread's stack is the whole amount of virtual memory reserved for it, regardless of how much of that happens to be backed by any physical storage at the moment.