From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p06EORkW009910 for ; Thu, 6 Jan 2011 15:24:27 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoCAItfJU1RZ90wkWdsb2JhbACkGRUBAQEBCQsKBxEDIb0phUwEiwk X-IronPort-AV: E=Sophos;i="4.60,283,1291590000"; d="scan'208";a="84546721" Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by mail4-smtp-sop.national.inria.fr with ESMTP; 06 Jan 2011 15:24:22 +0100 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110106142418.GHDI19887.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Thu, 6 Jan 2011 14:24:18 +0000 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20110106142418.KZJY25656.aamtaout04-winn.ispmail.ntl.com@romulus.metastack.com>; Thu, 6 Jan 2011 14:24:18 +0000 Received: from remus.metastack.local ([172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id p06EOEQn002511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jan 2011 14:24:15 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%11]) with mapi; Thu, 6 Jan 2011 14:20:40 +0000 From: David Allsopp To: Jim Pryor , "caml-list@inria.fr" Thread-Topic: [Caml-list] memory leak in toplevel? or, how to implement sizeof Thread-Index: AQHLraGsDB62oFoTk0ObCg77sNrfVJPD/TJA Date: Thu, 6 Jan 2011 14:20:38 +0000 Message-ID: References: <20110106130539.GB12229@vaio.hsd1.pa.comcast.net> In-Reply-To: <20110106130539.GB12229@vaio.hsd1.pa.comcast.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=YRQb3vVIxCoA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=a5GWVY9DlxOEFU8I_v4A:9 a=vj5-CqB-VuOAVtmCjp4A:7 a=7a5CJlC8NKUmJk-5yqTRqvony5EA:4 a=CjuIK1q_8ugA:10 a=UUUuHhUP8YCykPyF:21 a=Q0tQBYbeazdADrHm:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p06EORkW009910 Subject: RE: [Caml-list] memory leak in toplevel? or, how to implement sizeof Jim Pryor wrote: > Starting up the toplevel fresh, with no .ocamlinit file, I see this: > > $ /usr/bin/ocaml > Objective Caml version 3.12.0 > > # Gc.(compact();counters());; > - : float * float * float = (79217., 32932., 82668.) > # Gc.(compact();counters());; > - : float * float * float = (93530., 32932., 85816.) > # Gc.(compact();counters());; > - : float * float * float = (107843., 32932., 88964.) > > Why do both the minor_words and major_words keep climbing? Do these > indicate the number of words _ever_ allocated, The docs clearly state that is "ever" allocated - see type Gc.stat in the reference manual. > and so the overhead of > doing the garbage collection and compacting has pushed them up? Or do they > indicate the number of words _now_ allocated, so the fact that they > continue to climb indicates something is leaking memory? There are all kinds of things going on when you do this - even the result of Gc.counters causes an allocation (it has to create a tuple to return the numbers). The toploop uses the Parsing module to parse each expression and that will result in some allocations. Printf probably allocates as well (which is responsible for the displaying the output in the toploop). If you re-order the variables to do the three statements in a row and then print all nine results at the end then you'll see a rise which looks pretty consistent with just the allocation of your nine variables and the tuples coming from Gc.counters. David