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.8 required=5.0 tests=AWL,SPF_FAIL 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 C06E9BC69 for ; Wed, 14 Nov 2007 17:27:08 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEiwOkfAXQInh2dsb2JhbACPAwIBCAopgQ8 X-IronPort-AV: E=Sophos;i="4.21,417,1188770400"; d="scan'208";a="4458462" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 17:27:08 +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 lAEGR8i1005664 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 14 Nov 2007 17:27:08 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEiwOkdQW+UCh2dsb2JhbACPAwIBCAopgQ8 X-IronPort-AV: E=Sophos;i="4.21,417,1188770400"; d="scan'208";a="4458460" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 17:27:07 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsL3G-0000pM-Dj for caml-list@inria.fr; Wed, 14 Nov 2007 16:25:18 +0000 Received: from bas1-montreal42-1177928328.dsl.bell.ca ([70.53.194.136]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 16:25:18 +0000 Received: from monnier by bas1-montreal42-1177928328.dsl.bell.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 16:25:18 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Stefan Monnier Subject: Re: OCaml runtime using too much memory in 64-bit Linux Date: Wed, 14 Nov 2007 11:22:46 -0500 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: bas1-montreal42-1177928328.dsl.bell.ca User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) Cancel-Lock: sha1:Pc7xApmRA+w2cn1TJ3cwY9wnkdM= Sender: news X-Miltered: at concorde with ID 473B21DC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 runtime:01 allocating:01 initialized:01 orthogonal:01 heap:01 megabytes:02 bytes:03 bytes:03 size:95 brian:05 problem:05 table:93 table:93 linux:07 > and uses a page table for this purpose, with a dense representation > (an array of bytes). If the major heap areas are closely spaced, this [...] > For 32-bit platforms, this isn't much of a problem since the maximum > size of the page table is 1 megabytes. For 64-bit platforms, the sky How about allocating this array of bytes via mmap and then leave it uninitialized (relying on POSIX's guarantee that it's already initialized to zeros)? This way you can easily have a 4GB "dense" table which doesn't use much RAM since most of the 4GB will be mapped (via copy-on-write) to the same "zero page". Stefan PS: Obviously this is orthogonal to the potential change in page-size recommended by Brian.