From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <garrigue@math.nagoya-u.ac.jp>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 
	autolearn=disabled version=3.1.3
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38])
	by yquem.inria.fr (Postfix) with ESMTP id 52ECEBC6B
	for <caml-list@yquem.inria.fr>; Sat, 18 Aug 2007 02:07:40 +0200 (CEST)
Received: from rabbit.math.nagoya-u.ac.jp (rabbit.math.nagoya-u.ac.jp [133.6.130.5])
	by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7I07bpP023884
	for <caml-list@inria.fr>; Sat, 18 Aug 2007 02:07:39 +0200
Received: from localhost (rabbit-172 [172.16.254.254])
	by rabbit.math.nagoya-u.ac.jp (8.12.11/3.7W) with ESMTP id l7I07SkJ006892;
	Sat, 18 Aug 2007 09:07:28 +0900 (JST)
Date: Sat, 18 Aug 2007 09:07:27 +0900 (JST)
Message-Id: <20070818.090727.2004170775.garrigue@math.nagoya-u.ac.jp>
To: shiv@ece.ucsb.edu
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Stopping and continuing GC
From: Jacques GARRIGUE <garrigue@math.nagoya-u.ac.jp>
In-Reply-To: <B59A0D7C-FFE1-4393-A5BA-80EBD934A538@ece.ucsb.edu>
References: <B27F0313-86A3-4F82-ACEB-A76659809418@ece.ucsb.edu>
	<20070817.100453.94562786.garrigue@math.nagoya-u.ac.jp>
	<B59A0D7C-FFE1-4393-A5BA-80EBD934A538@ece.ucsb.edu>
X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Miltered: at discorde with ID 46C6384A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)!
X-Spam: no; 0.00; shivkumar:01 lablgtk:01 compaction:01 compaction:01 lablgtk:01 gmain:01 callbacks:01 dependencies:01 labltk:01 caml-list:01 shiv:02 explicitly:02 explicitly:02 callback:02 otoh:02 

From: Shivkumar Chandrasekaran <shiv@ece.ucsb.edu>

> 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.

You're right. I got confused when reading the code.
Since the overhead is raised, you have to call Gc.compact explicitly.
You can still compute the actual overhead by looking at free_words and
live_words in Gc.stat, so I would suggest something like:

open Gc

let check_for_compaction () =
  let gc = Gc.stat () in
  if gc.free_words > gc.live_words * 5 then Gc.compact ()

let cpct_id = GMain.Timeout.add ~ms:10000 ~callback:check_for_compaction

It would be possible to modify lablGTK to allow compaction during
other callbacks, but one would first have to read carefully the code
to see where the dependencies are.

This is for lablgtk. LablTk does not fiddle with compaction, so if you
have a problem you may just need to lower the compaction ratio.

Jacques Garrigue