From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id C548D7F1C3 for ; Fri, 23 Nov 2012 17:05:39 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.17.8; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.17.8; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.17.8 as permitted sender) identity=helo; client-ip=212.227.17.8; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioBAJOer1DU4xEIjWdsb2JhbABEhie6DhYOAQEBAQkJCwkSBSSCHgEBBAEjVgULCxoCJgICVwYTCYd+CgisOJJMgSKLFYMugRMDjWGJPIRPjUc X-IronPort-AV: E=Sophos;i="4.83,307,1352070000"; d="scan'208";a="182894582" Received: from moutng.kundenserver.de ([212.227.17.8]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Nov 2012 17:05:08 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-221-170.pools.arcor-ip.net [94.219.221.170]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MMtZ5-1TcArn0r5L-008Zfq; Fri, 23 Nov 2012 17:05:05 +0100 Received: from [192.168.5.106] (dslb-094-219-221-170.pools.arcor-ip.net [94.219.221.170]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id CEAC8C00CF; Fri, 23 Nov 2012 17:05:03 +0100 (CET) From: Gerd Stolpmann To: Chengqi Song Cc: caml-list@inria.fr In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 23 Nov 2012 17:05:04 +0100 Message-ID: <1353686704.6009.148.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:5TFW1J5cfYV6hs73lr6bMFWhAFb57JDDP2iBFIa+M2W wZwD1edlLP0Gzktqo4wniJ43dtgwXHfSA0GIKEzbZnm2latdqd NJFzDquX4HwHVcxAIoszt1IVQj4xRml+xI0PHya8MvH2mG8O9g 4JofnfZG33ES0NRoLRlJTd0Czrwbn3eorADraSIUjvPZF+Ja5k HxsIkyYbRh8wdmreZ2p6GMGk9JgjdS+2o471bFeGWrrXX7P17W 0eCJP1QuR9mSYsdKGP+IN/cIbcHewQOeH67KpGub9CRbuKVRri OhUcCPzmoo8MiHBNoy0CilcTMMNJY8O0oPKIHjxR0IC3IQ/78k J0uDWote8mhJb1J9qhVQSYb4WX0t6sNpYUNbY7Dqd Subject: Re: [Caml-list] Memory usage of ocaml program 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. ------------------------------------------------------------