On Sat, 26 Jul 2003 17:34:11 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > Sorry, I wasn't clear. I actually meant, that the stacks for new
> > threads are allocated at descending addresses (e.g. starting at
> > 0xf0000000, then 0xeffc0000, 0xeff80000, 0xeff40000,...) while the
> > heap
> > grows towards these addresses. So you have for heap and stacks the
> > full
> > range from 0x80000000 to 0xf0000000.
>
> Don't you forget place where to put the code, shared libraries,
> shared
> memory etc. into?
Those would live beyond 0xf0000000 or whatever limit is set. Actually
this strategy is not too far away from how it is done in R5; the
difference is basically that things are reordered such that the stacks
and the heap are neighbors and can both grow into the direction of the
free address space.
Though now that I think about it, is there any reason, why stacks and
shared objects couldn't be put into the same part of the address space?
Then areas for shared objects and shared memory would be placed using
the same strategy as I proposed for the stacks. An example:
0x0 0x80000000
-------------------------------------------------------------
| kernel | heap | ... free ... | stack1 | stack2 | add-on |
-------------------------------------------------------------
---------------------------------------------------------------
stack | executable data | executable shared | libbe.so data |
---------------------------------------------------------------
-------------------------------------------------------
libbe.so shared | libroot.so data | libroot.so shared |
-------------------------------------------------------
0xffffffff
> I haven't thought too much about the address space division for user
> land or kernel land much, but I will do introduce publicly what I am
> thinking of before changing the current implementation.
Cool. :-)
CU, Ingo