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=1.1 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id C3B1ABC6B for ; Fri, 17 Aug 2007 18:44:24 +0200 (CEST) Received: from gate.ece.ucsb.edu (gate.ece.ucsb.edu [128.111.56.56]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7HGiNOE031503 for ; Fri, 17 Aug 2007 18:44:24 +0200 Received: from mail.ece.ucsb.edu (mail.ece.ucsb.edu [128.111.56.210]) by gate.ece.ucsb.edu (8.13.1/8.13.1) with ESMTP id l7HGiFcm009381; Fri, 17 Aug 2007 09:44:16 -0700 Received: from [68.6.99.86] (ip68-6-99-86.sb.sd.cox.net [68.6.99.86]) (authenticated bits=0) by mail.ece.ucsb.edu (8.13.1/8.13.1) with ESMTP id l7HGiEJH006795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Aug 2007 09:44:15 -0700 In-Reply-To: <20070817.100453.94562786.garrigue@math.nagoya-u.ac.jp> References: <20070817.100453.94562786.garrigue@math.nagoya-u.ac.jp> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: caml-list@inria.fr Content-Transfer-Encoding: 7bit From: Shivkumar Chandrasekaran Subject: Re: [Caml-list] Stopping and continuing GC Date: Fri, 17 Aug 2007 09:44:14 -0700 To: Jacques Garrigue X-Mailer: Apple Mail (2.752.2) X-Milter: Spamilter (Reciever: gate.ece.ucsb.edu; Sender-ip: 128.111.56.210; Sender-helo: mail.ece.ucsb.edu;) X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-3.0rc3 (gate.ece.ucsb.edu [128.111.56.56]); Fri, 17 Aug 2007 09:44:16 -0700 (PDT) X-UCSB/ECE-MailScanner-Information: Please contact the ISP for more information X-UCSB/ECE-MailScanner: Found to be clean X-UCSB/ECE-MailScanner-From: shiv@ece.ucsb.edu X-Miltered: at concorde with ID 46C5D067.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; shivkumar:01 ocaml:01 lablgtk:01 compaction:01 lablgtk:01 compaction:01 --shiv--:01 2007,:98 wrote:01 heap:01 caml-list:01 shiv:02 explicitly:02 explicitly:02 otoh:02 On Aug 16, 2007, at 6:04 PM, Jacques Garrigue wrote: > This looks like a misunderstanding. > You cannot stop the GC in ocaml: it will be triggered as soon as the > young heap is full anyway. > What lablGTK does is turning off compaction, which is a rather new > feature of the GC (didn't exist when lablgtk was first written), which > moves around objects in the old generation, which would break some > assumptions in the code. As indicated, you can still call compaction > explicitly, a simple way being to call Gc.major once in a > while (using a timer for instance), as it will do compaction too when > needed. When I first read it I thought I got it... If I read you correctly, you are saying that lablGTK has tuned off compaction (somehow), but if I manually call Gc.major I can have it done. But, you also say that Gc itself is not turned off. But, I thought Gc.major was an intrinsic part of the gc cycle. Which would imply that compaction would be called anyway, even if I did not call Gc.major explicitly. Are you saying that the "major sweeps" (whatever Gc.major does) are also turned off.... OTOH, the manual says: > If max_overhead >= 1000000, compaction is never triggered. If lablGTK has set this, then presumably calling Gc.major will have no impact. Thanks for any clarifications. --shiv--