From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Chengqi Song <songcq@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Memory usage of ocaml program
Date: Fri, 23 Nov 2012 17:05:04 +0100 [thread overview]
Message-ID: <1353686704.6009.148.camel@thinkpad> (raw)
In-Reply-To: <CADjdUigz-nY8QNNcZfB_DdDonmPz-fGPFb6sFu1kxbNua-SdnQ@mail.gmail.com>
Am Freitag, den 23.11.2012, 10:34 +0800 schrieb Chengqi Song:
> I have the same program (same binary) running in different modes. From
> GC stats I see they're using the same amount of heap now (209m) and
> the stack is small. But in top's RES column, I see one is using 270m
> memory and the other one is using 622m. Forcing heap compaction does
> not change the numbers.
>
> I don't quite understand this difference. A program's memory usage
> should be code, static data, heap and stack. For the same binary, code
> and static data segment should be the same, and now that GC stats
> tells me heap and stack are the same, why there is a 352m difference
> in memory usage?
Here are some ideas:
- First, RES or RSS is not identical to the memory the program
has allocated. It is the memory that is currently used in RAM
(resident memory). This does not count memory swapped out,
memory-mapped files, and memory that was allocated but never written
to.
For a better impression what is happening look at the memory
map of the running process: On Linux this is /proc/$pid/maps, and on
OS X you can get it with the vmmap command.
- Sometimes it is not possible to give memory back to the
kernel. Normally, a program gets memory from the kernel
in big chunks, and it can only give it back when such a
chunk becomes empty, or when the chunk can be shrunk (i.e. memory
at the end of the chunk becomes empty). The details of this
are very OS-dependent. OCaml calls malloc/free, and does it very
best to free what is unused, but libc finally decides about the real
allocation chunks.
On traditional Unix there was even only one such chunk (called
"the heap"), and you could only extend or shrink it. When memory
became free in the middle of this chunk it could never be really
released.
On modern OS this is normally better, though, e.g. Linux libc
can manage several chunks. But nevertheless you can still
run into such issues.
Gerd
> Thanks
--
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details: http://www.camlcity.org/contact.html
Company homepage: http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------
prev parent reply other threads:[~2012-11-23 16:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-23 2:34 Chengqi Song
2012-11-23 6:40 ` Gabriel Scherer
2012-11-23 15:29 ` Edgar Friendly
2012-11-23 16:05 ` Gerd Stolpmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1353686704.6009.148.camel@thinkpad \
--to=info@gerd-stolpmann.de \
--cc=caml-list@inria.fr \
--cc=songcq@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox