mmap(MAP_ANONYMOUS) vs. malloc()
Michael Bresnahan
You can also do neat things like making pages of memory
read/write only.
If you mmap() a file, you get a number of other nifty
features. You could use it as just a fast disk I/O
mechanism or as persistant storage.
Note that mmap() is not "supported" on HP/UX 9.0. It is
there and has a man page (a misleading man page), but
doesn't do everything its supposed to do.
MikeB
Jens-Uwe Mager
(Tor Lillqvist) wrote:
> In what circumstances, if any, is it advantageous to allocate
> memory with mmap(0, size, PROT_URW, MAP_ANONYMOUS|MAP_PRIVATE,
> -1, 0) instead of malloc(size)?
If you allocate quite large chunks and you want to give the memory back to
the OS. As free() does just return the memory to a pool in your process
the swap space will remain allocated to your process. If you munmap() the
area instead, the swap space is available to other processes.
______________________________________________________________________________
Jens-Uwe Mager j...@anubis.han.de
30177 Hannover j...@helios.de
Brahmsstr. 3 Tel.: +49 511 660238
Raymond Nijssen
TL> In what circumstances, if any, is it advantageous to allocate
TL> memory with mmap(0, size, PROT_URW, MAP_ANONYMOUS|MAP_PRIVATE,
TL> -1, 0) instead of malloc(size)?
The main advantage is that if you munmap(2) a no longer needed mmap(2)ed
block, the corresponding memory is always handed back the system.
In contrast, space from the free-pool kept by malloc(3) is only returned to
the OS under very particular conditions that are not satisfied in most
programs. (Provided that the OS supports it, eg. unices that support sbrk(2)
with a negative argument, eg. HP-UX)
A disadvantage is that it is hard to port this technique, even among unices.
Note that the number of used mmapped ranges may be limited.
I wrote an experimental enhancement to gnu malloc that uses this technique
transparently for large blocks.
It works well, except that due to fragmentation the OS may after some time be
unable to find a fitting slot for a new block. This issue deserves some
attention.
-Raymond
--
Raymond X.T. Nijssen | If you can't fix it, don't break it.
|
Eindhoven University of Technology, Design Automation (ES) | tel. +31-402473614
EH 7.36, PO. Box 513, 5600 MB Eindhoven, The Netherlands | fax. +31-402464527
Vociferous Mole
Michael Bresnahan <mbres...@mmm.com> wrote:
>Note that mmap() is not "supported" on HP/UX 9.0. It is
>there and has a man page (a misleading man page), but
>doesn't do everything its supposed to do.
This is semi-true. It works just fine on 700 series machines. 800
series do not support MAP_SHARED.
--
The Mole - I think, therefore I scream
"Awww..."
"Don't let that 'sweet' act fool ya, Harry! They're DANGEROUS ASSASSINS!"
[Two guards from ZOT!]
Michael Bresnahan
It is supported on series 700 machines.
Sorry for the goof.
MikeB
Ken Green
: In article <41d42h$b...@dawn.mmm.com>,
: Michael Bresnahan <mbres...@mmm.com> wrote:
: >Note that mmap() is not "supported" on HP/UX 9.0. It is
: >there and has a man page (a misleading man page), but
: >doesn't do everything its supposed to do.
: This is semi-true. It works just fine on 700 series machines. 800
: series do not support MAP_SHARED.
This is only true at 9.0X. With 10 then the 800 series works to.
--
__________________email Ken....@kgcc.demon.co.uk _____________________
Ken Green Computer Consultancy
22 Matthews Chase, Binfield, Berkshire, RG42 4UR. U.K.
Marc Sabatella
> In what circumstances, if any, is it advantageous to allocate
> memory with mmap(0, size, PROT_URW, MAP_ANONYMOUS|MAP_PRIVATE,
> -1, 0) instead of malloc(size)?
In addition to what others have suggested, consider:
- the mmap method gives you zero-filled pages, which might be nice
- the mmap method gives you instant bounds checking - you did, of course, want
a bounds violation to trigger a core dump? :-)
- malloc is almost certainly a lot faster
- the VM system doesn't manage mmap regions as efficiently as malloc does
blocks; you don't want to do this often for small sizes, as you'll gets lots
of fragmentation
- I'll bet that VM performance degrades the more mmap'ed regions have in use
- there is probably a hard limit on the number of mmap'ed regions you can have
- I've seen code break when it assumes that the address of a malloc'ed region
will always be greater than the address of a global variable. Actually, the
code I saw break because of this assumption was, I think, the old "libmalloc"
implementation :-). Anyhow, it is conceivable that some code you have may be
unwittingly depending on traditional memory layout.
This was kind of fun...
--
Marc Sabatella
--
ma...@fc.hp.com
http://www.fortnet.org/~marc/
--
All opinions expressed herein are my personal ones
and do not necessarily reflect those of HP or anyone else.
pslh
Raymond Nijssen <ray...@es.ele.tue.nl> wrote:
>::: "TL" == Tor Lillqvist <t...@hemuli.tte.vtt.fi> writes:
>
> TL> In what circumstances, if any, is it advantageous to allocate
> TL> memory with mmap(0, size, PROT_URW, MAP_ANONYMOUS|MAP_PRIVATE,
> TL> -1, 0) instead of malloc(size)?
>
>The main advantage is that if you munmap(2) a no longer needed mmap(2)ed
>block, the corresponding memory is always handed back the system.
I have also used mmap() in situations where malloc() failed to allocate a
(typically very large) area of memory (errno==ENOMEM) but mmap()ing the
same amount of memory worked fine.
Hope this helps,
Paul
Paul Henshaw: Research Associate - Distributed Multimedia & Broadband Comms
Computing Laboratory, The University of Kent at Canterbury
Tel: +44 1227 827535 Fax: +44 1227 762811
http://alethea.ukc.ac.uk/Alethea/HoF/pslh.html