Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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.
------------------------------------------------------------


      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