QUESTION:
I think this is about the best place I can ask this. I hope you
can help, at least to get me started (pointed in the right
direction) in answering the following list of questions a good
customer of mine recently posed to me.
1) If the user stack must reside in Segment 2 (I'm for now ignoring the
in the Large Program Support Overview which states that the user stac
be relocated into the shared memory segment), is it correct then tha
STACK default should be set to 65536 and not -1 in the limits file?
2) Is the shared memory segment register 13?
3) Does the STACK parameter refer to the total of both the user stack an
the kernel stack or just the user stack?
4) What are the IBM definitions for user stack and kernel stack?
5) Is the initialized program data stored with the executable (object co
in register #1?
6) Is the uninitialized data stored in Register #2 in the user data port
of the register for small models(less than 256)?
7) The use of -1 for the data default in the limits file is troubling.
Is this just for now an oversight by IBM? It would appear to me that
a program could get out of control and absorb all the available memory
in registers 3 through 10 in addition to register 2? I only went
to register 10 because the documentation said only 8 additional regis
could be referenced. Why only 8. Why not 10? Up to register 12.
8) This is my understanding of a problem program that would apply to que
number 7. Is it a correct understanding? I could build a C program
uses a simple linked list data structure. The program enters a loop
continues to perform malloc's. Is it conceivable that my program wo
continue to run until all the memory in the registers 2 through 10 ar
The program would then core dump after the last failed malloc. Where
the core dump go if all available memory is used? Would the machine
the machine lock up?
---------- ---------- ---------- --------- ---------- ----------
A: 1) Q: ...is it correct then that the STACK default should be
set to 65536 and not -1 in the limits file?
A: No, this is not correct. If you do indeed ignore the
Large Program Support (i.e., you do not compile with the
-bmaxdata option), then the stack cannot grow to a size
larger than a single segment (256 MB). By setting the
limit to -1 (unlimited), this just allows the stack to
grow until it hits the heap. Here is a diagram:
SEGMENT 2 (POINTED TO BY REGISTER 2)
------------------------------------
¢ ¢ <- Highest address
¢ USER INFORMATION ¢
¢ ¢
¢----------------------------------¢
¢ ¢
¢ THE MYSTERIOUS RED ZONE ¢
¢ ¢
¢----------------------------------¢
¢ ¢
¢ STACK ¢
¢ ¢ ¢
¢ ¢ Grows ¢ <- The stack pointer
¢ ¢¢¢¢¢ Downward ¢ is somewhere in
¢ ¢¢¢ ¢ here
¢ ¢ ¢
¢ ¢
¢**********************************¢ <- Stack soft limit
¢ ¢
¢XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX¢ <- Stack hard limit
¢ ¢
¢ ¢
¢ ¢
¢ ¢
¢ ¢
¢ ¢
¢ ¢ ¢
¢ ¢¢¢ ¢
¢ ¢¢¢¢¢ ¢
¢ ¢ Grows ¢ <- The sbrk pointer
¢ ¢ Upward ¢ is somewhere in
¢ HEAP ¢ here. malloc
¢ ¢ moves sbrk up.
¢----------------------------------¢
¢ ¢
¢ INITIALIZED AND UNINITIALIZED ¢
¢ VARIABLES AND CONSTANTS ¢
¢ ¢
------------------------------------
Without using large program support, the stack cannot
grow outside of this segment. With STACK set to -1, the
hard limit is, for all intents and purposes, removed,
and the stack size is limited only by the current size
of the heap. This is the default setting because it
gives each process as much stack space as possible
within the process's private segment (pointed to by
register 2).
2) Q: Is the shared memory segment register 13?
A: Yes.
3) Q: Does the STACK parameter refer to the total of both the
user stack and the kernel stack or just the user stack?
A: Just the user stack.
4) Q: What are the IBM definitions for user stack and kernel
stack?
A: USER STACK: Memory space used by processes to store
process private local variables and process private
subroutine return information.
KERNEL STACK: Memory space allocated from the kernel's
memory space which serves to store local variable and
subroutine return information when a process is running
in kernel mode (for example, when a process makes a call
to a kernel routine). The kernel contains kernel stack
space for each process.
5) Q: Is the initialized program data stored with the
executable object code in register 1?
A: Yes, but this is never used. Allow me to explain. The
segment pointed to by register 1 contains the executable
object code, and the executable object code contains
initialized program data. This information is NEVER
accessed, however, by the process. ONLY THE LOADER
accesses this information.
As far as the process is concerned, initialized program
data is stored in the segment pointed to by register 2,
in user data space. See the diagram of memory that I
created for question number 1.
6) Q: Is the uninitialized data stored in register 2 in the
user data portion of the register for small models?
A: Yes.
7) Q: The use of "-1" for the data default in the limits file
is troubling. Is this just for now an oversight by IBM?
It would appear to me that a program could get out of
control and absorb all the available memory in registers
2 through 10.
A: Fortunately, it is not quite that simple. First notice
that unless the developer of the program compiles with
large program support, then the process cannot access
more than 256 MB (1 segment) of data anyway. All other
addresses will be out of the program's address space.
At some point a program might overwrite its own
stack, which will simply cause its behavior to become
undefined. At this point, the program could conceivably
destroy anything to which it has write access, but it
would take an amazing coincidence for the program to do
anything but maybe produce one or two invalid results and
then die with a segmentation violation as soon as it
tried to execute a return from a function.
Furthermore, if a process was compiled with the large
program support, and if the developer had requested access
to the maximum of 2 gigabytes (GB) of memory, the program
still could not hurt anything simply by absorbing memory.
You must keep in mind that a process works in virtual
memory. The size of virtual memory is limited by the
size of paging space. If a program compiled for 2 GB
access tries to access all its memory, then either the
system will have enough paging space (more than 2 GB) to
support this and all other processes on the system, or
it will not have enough paging space. If it does indeed
have enough paging space, then the logical execution of
the program and of all other processes on the system
will run properly (though if the real memory is much
less than 2 GB then the system may experience a serious
slowdown, a condition commonly called "thrashing").
If the system has less than 2 GB of paging space, then
when the paging space falls below a certain level, AIX
will detect a low paging space condition. If the
condition is not corrected, AIX will start killing
processes in a logical manner. Sooner or later AIX will
kill the process which is trying to access 2 GB. If you
need to know the exact scheme for determining which
process is the next to be killed in a low paging space
condition, then please respond back as that will require
further research.
Q: Why only 8 (registers are available for process data
space)?
A: The system reserves 2 registers for attaching shared
memory segments only. I can only speculate as to why
this was done. Once the loader assigns a register to
a segment, you cannot detach from that segment. Thus,
if you use all your registers, you cannot attach to any
shared segments. I speculate that development wanted to
avoid this situation. The reasoning behind decisions
made by development is not generally documented and we
have no access to this information.
8) Q: Can a simple linked-list building program repeatedly
issue mallocs until all memory in registers 2 through
10 is used?
A: Yes, it is conceivable if the program was compiled with
large program support. If the program was not compiled
with large data support, then it will only fill up
segment 2. In any case, the worst thing that typically
will happen is AIX will kill the process.
Q: Where would a core dump go if all memory is used?
A: Again, you must remember that a process works only
within its virtual memory. This virtual memory can
never be all of paging space because AIX will kill a
process before it allows the process to use up all the
available space. If the system has enough memory to
support more than 2 GB of paging space, then when the
large process attempts to cross the 2 GB boundary,
malloc will realize that the process is out of memory
and it will take appropriate action. It will be able to
take appropriate action because AIX will page out the
normal program code if necessary in order to make room
for malloc to run.
If the system cannot support more than 2 GB of paging
space, then as soon as AIX feels threatened by the large
process (i.e., when the process attempts to lower the
amount of unused paging space below a safety level),
AIX will kill it.
Thus, a core dump would proceed normally if the program
ever even reached the point at which it filled all its
space.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q676831 FFKSW
Additional search words:
ANSWER COMPILERS DEFAULTS FFKSW IX JAN95 KERNEL LIMITS OZNEW
PROGRAMMING QUESTION RISCL RISCSYSTEM SEG SEGM SEGMENT SEGMENTATION
SEGMENTED SEGMENTING SOFTWARE SPACE SPACING STACK STACKER
HR
CENTER
FONT size=2WWQA: ITEM: RTA000053124 ITEM: RTA000053124
BRDated: 06/1996 Category: RISCL
BRThis HTML file was generated 99/06/24~12:43:21
BRComments or suggestions?
A href="../../../../feedback.html"BContact us/B/ABR
/FONT
/CENTER
/BODY
/HTML