From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id CE4E7BC69 for ; Wed, 14 Nov 2007 18:26:53 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIO+OkfR4q8Znmdsb2JhbACPAwIBAQcEBgkIGA X-IronPort-AV: E=Sophos;i="4.21,417,1188770400"; d="scan'208";a="4463685" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 18:26:53 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id lAEHQrFB008147 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 14 Nov 2007 18:26:53 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIO+OkfR4q8Znmdsb2JhbACPAwIBAQcEBgkIGA X-IronPort-AV: E=Sophos;i="4.21,417,1188770400"; d="scan'208";a="4463682" Received: from tomts5.bellnexxia.net (HELO tomts5-srv.bellnexxia.net) ([209.226.175.25]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 18:26:52 +0100 Received: from pastel.home ([70.53.194.136]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20071114172651.SDDQ17217.tomts5-srv.bellnexxia.net@pastel.home> for ; Wed, 14 Nov 2007 12:26:51 -0500 Received: by pastel.home (Postfix, from userid 20848) id 91F367F4E; Wed, 14 Nov 2007 12:26:50 -0500 (EST) From: Stefan Monnier To: Brian Hurt Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: OCaml runtime using too much memory in 64-bit Linux Message-ID: References: <4731F5D1.2070405@janestcapital.com> <1194459622.15728.94.camel@localhost.localdomain> <47320E10.1050307@janestcapital.com> <200711140520.46016.romain.beauxis@gmail.com> <8ef825670711140403m464c01detff5537abb2211946@mail.gmail.com> <473AF04C.7030107@inria.fr> <473B2400.5050800@janestcapital.com> Date: Wed, 14 Nov 2007 12:26:50 -0500 In-Reply-To: <473B2400.5050800@janestcapital.com> (Brian Hurt's message of "Wed, 14 Nov 2007 11:36:16 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at concorde with ID 473B2FDD.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 runtime:01 allocates:01 optimistic:98 caml-list:01 kernel:02 kernel:02 allocated:02 allocated:02 seems:03 bytes:03 bytes:03 fix:05 exists:05 underlying:06 > Even on a system like linux, which optimistically allocates memory (i.e. the > actually underlying memory isn't allocated until you actually touch it), > once you read the page, it has to actually exist in memory. It exists in memory: it's the zero page (a page that contains all zero bytes). And it's the same physical (RAM) page used for all pages that have been allocated but not yet written. So as long as you don't write to it, it shouldn't use any RAM space. Of course, it may cost in swap use (depending on optimistic allocation and the use of MAP_NORESERVE), and it will cost in kernel memory because the kernel has to maintain the process's page table. But it seems like a good quick fix, which preserves the advantages of a dense array of bytes (i.e. fast and simple lookup, compact representation using less cache space, ...). Stefan