Stopping and continuing GC

Stopping and continuing GC

[Shivkumar Chandrasekaran]

I noticed that both lablTK and lablGTK turn off GC and recommend  
using it within callbacks where it is safe. My program consumes tons  
of memory and I need to continue GC at the start of my callbacks and  
stop it again as I exit, frequently in the code. Are there any easy /  
standard Gc.___ calls to do the job "correctly". Thanks in advance,

--shiv--\

Re: [Caml-list] Stopping and continuing GC

[Jacques Garrigue]

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

> I noticed that both lablTK and lablGTK turn off GC and recommend  
> using it within callbacks where it is safe. My program consumes tons  
> of memory and I need to continue GC at the start of my callbacks and  
> stop it again as I exit, frequently in the code. Are there any easy /  
> standard Gc.___ calls to do the job "correctly". Thanks in advance,

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. My understanding is that compaction is atomic, so there is no
notion of starting and stopping it, just of allowing it or not.
I don't remember anything similar in LablTk.

In usual practice, you should not have to do anything special.

Jacques Garrigue

Re: [Caml-list] Stopping and continuing GC

[Markus Mottl]

On 8/16/07, Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> wrote:
> My understanding is that compaction is atomic, so there is no
> notion of starting and stopping it, just of allowing it or not.

This, btw., raises an interesting question: are there any ways (and
hopefully even intentions) to make compaction work in slices like the
major GC does?  We write extremely latency sensitive applications and
often even have to manually control when the GC performs collections.

Unfortunately, compaction cannot be controlled in the same way as the
major GC can be (e.g. calling the major GC with a specific slice
size).  That's why we have to turn off automatic compactions, too, and
run these latency sensitive applications on machines with very large
amounts of memory.

Are there any intentions to remedy this situation?

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: [Caml-list] Stopping and continuing GC

[Richard Jones]

On Fri, Aug 17, 2007 at 10:05:41AM -0400, Markus Mottl wrote:
> This, btw., raises an interesting question: are there any ways (and
> hopefully even intentions) to make compaction work in slices like the
> major GC does?  We write extremely latency sensitive applications and
> often even have to manually control when the GC performs collections.
> 
> Unfortunately, compaction cannot be controlled in the same way as the
> major GC can be (e.g. calling the major GC with a specific slice
> size).  That's why we have to turn off automatic compactions, too, and
> run these latency sensitive applications on machines with very large
> amounts of memory.

I looked at the code in byterun/compact.c (I've been looking at the
internals of the GC quite a bit this week) and at first glance it
seems like it overwrites headers in the heap temporarily while
compacting.  So any incremental compactor looks like it would involve
quite a rewrite.

But I wonder in general terms about the problem you are having, which
is surely a fragmentation issue (exactly the same as you'd see in a C
program).  Can this be cured by examining what sizes of structures you
are allocating?  Perhaps you can pad out or trim common structures so
that they are the same size, thus avoiding fragmentation?  A second
possibility is that it's an interaction between the OCaml heap blocks
and the underlying C malloc allocator.  It might be that OCaml is
requesting allocations which always require more memory from the
operating system (ie. they are too large or awkwardly sized to satisfy
from free areas within the current C heap).  It should be relatively
easy to diagnose either situation: For the first you'd need a program
to walk the Caml heap looking at the sizes of blocks, which you'd run
in a process that has been running for some time.  For the second,
instrument calls to malloc (in caml_alloc_for_heap).

That's just from a cursory look at the code anyway -- there is
probably much that I'm missing, but instrumenting those would be a
start.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Stopping and continuing GC

[Shivkumar Chandrasekaran]

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

Re: [Caml-list] Stopping and continuing GC

[Richard Jones]

On Fri, Aug 17, 2007 at 09:44:14AM -0700, Shivkumar Chandrasekaran wrote:
> Are you saying that the "major sweeps" (whatever Gc.major does) are  
> also turned off....

No.

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

Precisely.  If you grab the actual code (byterun/compact.c) you will
see:

  void caml_compact_heap_maybe (void)
  {
    float fw, fp;
                                      Assert (caml_gc_phase == Phase_idle);
    if (caml_percent_max >= 1000000) return;

The GC runs in phases (and slices of work within some phases) and will
call this function when it has just finished a complete round of
collecting the major heap.  However this function won't do anything if
that max_overhead setting is as above.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Stopping and continuing GC

[Jacques GARRIGUE]

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