ClarkThan · September 19, 2024 11:00 · Jan 25, 2014 · Jan 25, 2014 · Jan 25, 2014 · Jan 24, 2014
diff --git a/Stack.md b/Stack.md
@@ -3,7 +3,7 @@ Why stack grows down
 
 Any running process has several memory regions: code, read-only data, read-write data, et cetera. Some regions, such as code and read-only data, are static and do not change over time. Other regions are dynamic: they can expand and shrink. Usually there are two such regions: dynamic read-write data region, called **heap**, and a region called **stack**. Heap holds dynamic memory allocations, and stack is mostly used for keeping function frames.
 
-Both stack and heap grow. An OS doesn't know in advance whether stack or heap will be used predominantly. Therefore, an OS must layout these two memory regions in a way to guarantee maximum space for both. And here is the solution:
+Both stack and heap can grow. An OS doesn't know in advance whether stack or heap will be used predominantly. Therefore, an OS must layout these two memory regions in a way to guarantee maximum space for both. And here is the solution:
 
    1. Layout static memory regions at the edges of process's virtual memory
    2. Put heap and stack on edges too, and let them grow towards each other: one grows up, one grows down

diff --git a/Stack.md b/Stack.md
@@ -38,5 +38,5 @@ processors (e.g. B5000) where stack grows up. Some architecrures (e.g. System Z,
 allow to choose stack direction. SEAforth/GreenArrays, SPARC processors have cyclical stack.
 
 Author: Sergey Lyubka, January 2014  
-Corrected by: Vsevolod Stakhov, January 2014
+Corrected by: Vsevolod Stakhov, January 2014  
 Corrected by: Peter Sovietov, January 2014
diff --git a/Stack.md b/Stack.md
@@ -33,5 +33,10 @@ Many threads can consume a lot of virtual space, which can be a problem on 32-bi
 E.g. a program with 2000 threads, each taking a default of 1M stack size, eats about 2G
 or virtual memory, leaving very little space for heap. In such case, thread stack size should be reduced.
 
+In the majority of modern architectures, stack grows down. However, there are some
+processors (e.g. B5000) where stack grows up. Some architecrures (e.g. System Z, RCA1802A)
+allow to choose stack direction. SEAforth/GreenArrays, SPARC processors have cyclical stack.
+
 Author: Sergey Lyubka, January 2014  
-Corrected by: Vsevolod Stakhov, January 2014
+Corrected by: Vsevolod Stakhov, January 2014
+Corrected by: Peter Sovietov, January 2014
diff --git a/Stack.md b/Stack.md
@@ -33,5 +33,5 @@ Many threads can consume a lot of virtual space, which can be a problem on 32-bi
 E.g. a program with 2000 threads, each taking a default of 1M stack size, eats about 2G
 or virtual memory, leaving very little space for heap. In such case, thread stack size should be reduced.
 
-Author: Sergey Lyubka, 2014  
-Corrected by: Vsevolod Stakhov
+Author: Sergey Lyubka, January 2014  
+Corrected by: Vsevolod Stakhov, January 2014
diff --git a/Stack.md b/Stack.md
@@ -33,5 +33,5 @@ Many threads can consume a lot of virtual space, which can be a problem on 32-bi
 E.g. a program with 2000 threads, each taking a default of 1M stack size, eats about 2G
 or virtual memory, leaving very little space for heap. In such case, thread stack size should be reduced.
 
-Author: Sergey Lyubka, 2014
+Author: Sergey Lyubka, 2014  
 Corrected by: Vsevolod Stakhov
diff --git a/Stack.md b/Stack.md
@@ -33,4 +33,5 @@ Many threads can consume a lot of virtual space, which can be a problem on 32-bi
 E.g. a program with 2000 threads, each taking a default of 1M stack size, eats about 2G
 or virtual memory, leaving very little space for heap. In such case, thread stack size should be reduced.
 
-Author: Sergey Lyubka, 2014
+Author: Sergey Lyubka, 2014
+Corrected by: Vsevolod Stakhov
diff --git a/Stack.md b/Stack.md
@@ -29,8 +29,8 @@ maximum stack size of the main thread. Thread API allows to set stack size.
     |---| DLLs | code | data | heap |-->    <--| stack 2 |  <--| stack 1 | kernel |
     0                                                                    3G      4G
 
-Many threads can consume a lot of virtual space, which could be a problem on 32-machine.
+Many threads can consume a lot of virtual space, which can be a problem on 32-bit machine.
 E.g. a program with 2000 threads, each taking a default of 1M stack size, eats about 2G
-or virtual memory, leaving very little for heap. In such case, thread stack size should be reduced.
+or virtual memory, leaving very little space for heap. In such case, thread stack size should be reduced.
 
 Author: Sergey Lyubka, 2014
diff --git a/Stack.md b/Stack.md
@@ -24,7 +24,7 @@ Here's the simplified illustration of the memory map (Windows uses similar layou
 That is fine for single-threaded programs. Multi-threading requires separate stack
 for each thread. Therefore, main thread's stack begins at it's usual place - at the
 kernel boundary. Next thread's stack starts from some offset that  defines the
-maximum stack size of the main thread. Thread API provides a way to set the stack size.
+maximum stack size of the main thread. Thread API allows to set stack size.
 
     |---| DLLs | code | data | heap |-->    <--| stack 2 |  <--| stack 1 | kernel |
     0                                                                    3G      4G

diff --git a/Stack.md b/Stack.md
@@ -22,10 +22,9 @@ Here's the simplified illustration of the memory map (Windows uses similar layou
     (first page is never mapped to catch NULL dereferences)
 
 That is fine for single-threaded programs. Multi-threading requires separate stack
-for each thread. Therefore, main thread's stack begins at it's usual place - at a
-kernel boundary. Next thread's stack starts from some offset, that offset determines
-a maximum stack size of the main thread. Thread API provides a mean of setting
-stack size.
+for each thread. Therefore, main thread's stack begins at it's usual place - at the
+kernel boundary. Next thread's stack starts from some offset that  defines the
+maximum stack size of the main thread. Thread API provides a way to set the stack size.
 
     |---| DLLs | code | data | heap |-->    <--| stack 2 |  <--| stack 1 | kernel |
     0                                                                    3G      4G

diff --git a/Stack.md b/Stack.md
@@ -1,21 +1,21 @@
 Why stack grows down
 ====================
 
-Any running process has several memory regions: code, read-only data, read-write data, etcetera. Some regions, such as code and read-only data, are static and do not change over time. Other regions are dynamic: they can expand and shrink. Usually there are two such regions: dynamic read-write data region, called **heap**, and a region called **stack**. Heap holds dynamic memory allocations, and stack is mostly used for keeping function frames.
+Any running process has several memory regions: code, read-only data, read-write data, et cetera. Some regions, such as code and read-only data, are static and do not change over time. Other regions are dynamic: they can expand and shrink. Usually there are two such regions: dynamic read-write data region, called **heap**, and a region called **stack**. Heap holds dynamic memory allocations, and stack is mostly used for keeping function frames.
 
 Both stack and heap grow. An OS doesn't know in advance whether stack or heap will be used predominantly. Therefore, an OS must layout these two memory regions in a way to guarantee maximum space for both. And here is the solution:
 
    1. Layout static memory regions at the edges of process's virtual memory
    2. Put heap and stack on edges too, and let them grow towards each other: one grows up, one grows down
 
 This solution is reflected in a hardware design: most CPUs have support for stack, and it grows down.
-For example, 32-bit Linux implements this layout in a following way:
+For example, 32-bit Linux implements this layout in the following way:
    * code, shared libraries and read-only data are mapped at the beginning of the memory
    * then goes heap that grows up
    * kernel is mapped at the last 1G
-   * stack starts at kernel's boundary and grows down
+   * stack starts at kernel's lower boundary and grows down
 
-Here's a simplified illustration of the memory map (Windows uses similar layout):
+Here's the simplified illustration of the memory map (Windows uses similar layout):
 
     |---| DLLs | code | data | heap |-->      <---| stack | kernel |
     0                                                     3G       4G

diff --git a/Stack.md b/Stack.md
@@ -1,9 +1,9 @@
 Why stack grows down
 ====================
 
-Any running process has several memory regions: code, read-only data, read-write data, etcetera. Some regions, like code and read-only data, are static and do not change with time. Other regions are dynamic: they can expand and shrink. Usually there are two such regions: dynamic read-write data region, called **heap**, and a region called **stack**. Heap is used for holding dynamic memory allocations, and stack is mostly used for keeping function frames.
+Any running process has several memory regions: code, read-only data, read-write data, etcetera. Some regions, such as code and read-only data, are static and do not change over time. Other regions are dynamic: they can expand and shrink. Usually there are two such regions: dynamic read-write data region, called **heap**, and a region called **stack**. Heap holds dynamic memory allocations, and stack is mostly used for keeping function frames.
 
-Both stack and heap grow. The OS doesn't know in advance which will be used predominantly. Therefore, an OS must layout these two memory regions in a way to guarantee maximum space for both. And here is the solution:
+Both stack and heap grow. An OS doesn't know in advance whether stack or heap will be used predominantly. Therefore, an OS must layout these two memory regions in a way to guarantee maximum space for both. And here is the solution:
 
    1. Layout static memory regions at the edges of process's virtual memory
    2. Put heap and stack on edges too, and let them grow towards each other: one grows up, one grows down

diff --git a/Stack.md b/Stack.md
@@ -0,0 +1,37 @@
+Why stack grows down
+====================
+
+Any running process has several memory regions: code, read-only data, read-write data, etcetera. Some regions, like code and read-only data, are static and do not change with time. Other regions are dynamic: they can expand and shrink. Usually there are two such regions: dynamic read-write data region, called **heap**, and a region called **stack**. Heap is used for holding dynamic memory allocations, and stack is mostly used for keeping function frames.
+
+Both stack and heap grow. The OS doesn't know in advance which will be used predominantly. Therefore, an OS must layout these two memory regions in a way to guarantee maximum space for both. And here is the solution:
+
+   1. Layout static memory regions at the edges of process's virtual memory
+   2. Put heap and stack on edges too, and let them grow towards each other: one grows up, one grows down
+
+This solution is reflected in a hardware design: most CPUs have support for stack, and it grows down.
+For example, 32-bit Linux implements this layout in a following way:
+   * code, shared libraries and read-only data are mapped at the beginning of the memory
+   * then goes heap that grows up
+   * kernel is mapped at the last 1G
+   * stack starts at kernel's boundary and grows down
+
+Here's a simplified illustration of the memory map (Windows uses similar layout):
+
+    |---| DLLs | code | data | heap |-->      <---| stack | kernel |
+    0                                                     3G       4G
+    (first page is never mapped to catch NULL dereferences)
+
+That is fine for single-threaded programs. Multi-threading requires separate stack
+for each thread. Therefore, main thread's stack begins at it's usual place - at a
+kernel boundary. Next thread's stack starts from some offset, that offset determines
+a maximum stack size of the main thread. Thread API provides a mean of setting
+stack size.
+
+    |---| DLLs | code | data | heap |-->    <--| stack 2 |  <--| stack 1 | kernel |
+    0                                                                    3G      4G
+
+Many threads can consume a lot of virtual space, which could be a problem on 32-machine.
+E.g. a program with 2000 threads, each taking a default of 1M stack size, eats about 2G
+or virtual memory, leaving very little for heap. In such case, thread stack size should be reduced.
+
+Author: Sergey Lyubka, 2014