User: Password:
|
|
Subscribe / Log in / New account

Reorganizing the address space

Reorganizing the address space

Posted Jul 1, 2004 17:19 UTC (Thu) by ngmr (guest, #4393)
Parent article: Reorganizing the address space

Hmm, I wonder what stack size is reserved for a process' stack size resource limit of 'unlimited' (I assume it is picked up from the 'ulimit -s' setting).

From observation, I believe that malloc() will suballocate memory from the mmap() region if it needs / wants to, anyway.

So the distinction between the "heap" and "mmap" sections are less distinct than that presented, I believe. Only "statically" allocated memory (eg. for the data for static & global variables in C), is allocated "exclusively" from the "heap" section.

The general run of applications don't particularly care how memory is laid out, and therefore shouldn't be adversely effected by any change.

However, the category of application that this change is probably trying to address (the "memory hogs" referred to above) are probably precisely those that take special measures to try and achieve the best results from the existing memory layout.

They are also, therefore, most liable to (arguably) "legitimate" breakage when the layout scheme is changed, and most impacted if the ramifications of any such change are not fully thought through.


(Log in to post comments)

Reorganizing the address space

Posted Jul 3, 2004 5:46 UTC (Sat) by Ross (guest, #4065) [Link]

It's sbrk(2) vs. mmap(2). Calling malloc(3) usually results in a call
to sbrk(2) if there is not enough free space, but sometimes, in some
implementations, it can result in a call to mmap(2).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds