Version française
Home     About     Download     Resources     Contact us    
Browse thread
Stopping and continuing GC
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques GARRIGUE <garrigue@m...>
Subject: Re: [Caml-list] Stopping and continuing GC
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