🚀 go-pugleaf

In article <MLM.95Sep23040448@vegas.cs.brown.edu>,
Moises Lejter <mlm@cs.brown.edu> wrote:
 >In article <43qh32INN3hl@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
 >
 >  Kazimir> Once you allocate a certain number of pages which are made
 >  Kazimir> to appear as a linear block, you still face the possiblity
 >  Kazimir> of wastefully fragmenting the space. The underlying VM
 >  Kazimir> system doesn't know about your used and unused areas.
 >  Kazimir> Library functions like malloc() will typically _not_ free a
 >  Kazimir> frame of memory that is completely within an allocation
 >  Kazimir> chunk that has just been freed.
 >
 >I think this is mostly (perhaps only ;-) ) because UNIX systems do not
 >typically let you "unallocate" a page totally within the process'
 >virtual memory space (no function is provided that does so).  The only
 >function available to manipulate memory is sbrk(), which can request
 >more (or sometime? return) memory at the end of the current process vm
 >space.  The GNU allocator, for example, will return to the system
 >pages of vm at the end of the heap, if all allocated blocks within
 >those pages are freed.

That's not quite true.  In addition to sbrk(), UNIX can allocate memory
anywhere in your address space using anonymously mapped segments.
Mapped segments can represent an underlying file, or they can just be
pure virtual memory.

Mapping is rarely done page by page, though. :)
-- 
PGP key id is 0xD3C7995D.
Molybdenum 95! Got your ounce of fission byproduct yet?