WWW-www.enlightenment.org pushed a commit to branch master.
http://git.enlightenment.org/website/www-content.git/commit/?id=fca7b6ba65b81292835ee4a856800bf9f2fa43fa
commit fca7b6ba65b81292835ee4a856800bf9f2fa43fa
Author: Raster <ras...@rasterman.com>
Date: Wed Jun 17 23:02:02 2015 -0700
Wiki page start changed with summary [] by Raster
---
pages/docs/c/start.txt | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/pages/docs/c/start.txt b/pages/docs/c/start.txt
index 233243b..7456794 100644
--- a/pages/docs/c/start.txt
+++ b/pages/docs/c/start.txt
@@ -493,15 +493,17 @@ Generally you allocate memory with functions such as
''malloc()'', ''calloc()'',
==== Stack and heap ===
-The memory of your process, other than memory used to store the
code/instructions loaded from disk, is primarily made up of 2 elements. The
[[http://en.wikipedia.org/wiki/Call_stack|stack]] and the
[[http://en.wikipedia.org/wiki/Memory_management|heap]].
+The memory of your process, other than memory used to store the
code/instructions loaded from disk, is primarily made up of 2 elements. The
[[http://en.wikipedia.org/wiki/Call_stack|stack]] and the
[[http://en.wikipedia.org/wiki/Memory_management|heap]]. Your memory space will
generally look something as follows, often with the stack high up in memory (at
high addresses) and pieces of code from the process and libraries mapped in
from disk, as well as heap space being allocated there too [...]
-The stack is managed for you mostly by the compiler and runtime. As the
application runs, every time a function is called, a new blob of memory is
"pushed" at the "top" of the stack. This memory contains the parameters passed
to the function, and will contain return values from the function as well as a
return address to go back (to read instructions from) to when this function
returns. It is a very simple structure, and yet incredibly useful. Note that
stack often have limited sizes (so [...]
+{{ memstackheap.svg?nolink |Complete memory space diagram }}
-The heap is where more permanent memory is stored, and data here remains until
explicitly freed. Most objects and larger data will life here. Getting memory
in the heap is more costly in terms of time, but the limit on memory in the
heap is generally "all available memory on the system", given caveats of
fragmentation of memory, and possible process allocation limits imposed by the
OS.
+The stack is managed for you mostly by the compiler and runtime. As the
application runs, every time a function is called, a new blob of memory is
"pushed" at the "top" of the stack (conceptually stacks grow.. thus the top is
where the newest item(s) are on the stack, but often the stack grows down in
memory, so to push you subtract values from the top of the stack and to pop,
you add again). This memory contains the parameters passed to each function,
and will contain return values from [...]
+
+The heap is where more permanent memory is stored. Data here remains until
explicitly freed. Most objects and larger data will live here. Getting memory
in the heap is more costly in terms of time taken to allocate it or free it
(but once allocated, access cost is the same). The limit on memory in the heap
is generally "all available memory on the system", given caveats of
fragmentation of memory, and possible process allocation limits imposed by the
OS.
==== Libraries ====
-A shared library is simple a large bit of code you can "load" when your
application (or library) is loaded, where the code in it is shared with other
users on the system. It mostly is provided by another group of developers, and
thus may change its internals without your application or library needing to be
re-compiled. If there is a bug in the library it may be fixed later on by an
update to the library. Everyone who installs the update gets the fix. Same for
new features. Libraries hav [...]
+A shared library is simple a large bit of code you can "load" when your
application (or library) is loaded, where the code in it is shared with other
users on the system. It mostly is provided by another group of developers, and
thus may change its internals without your application or library needing to be
re-compiled. If there is a bug in the library it may be fixed later on by an
update to the library. Everyone who installs the update gets the fix (next time
the process is executed). [...]
If you want to do something privileged, or hide data, it needs to cross a
process boundary. Normally you'll speak some form of IPC to a privileged "root"
process for example. Of course all of this "we share everything" with libraries
also means that code in your application could corrupt/mess/destroy data the
library is maintaining, as well as vice-versa. There is no protection between a
library, another library and your process. This lack of protection means
performance is very good and [...]
--
