Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Can GC be BLOCKed?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-12-01 (18:53)
From: Neal Wang <>
Subject: Re: [Caml-list] Can GC be BLOCKed?
The problem is not caused by real-time requirement.
Let me explain it in more details:

1. a sqlite3 database is used store mutable objects (objects are
marshaled as strings and stored as BLOB in DB. The objects are very
large and have variant sizes)

2. Weak module is used to cache these objects.

3. Finalise function is used to write back the change of these in
memory objects into the sqlite3 database when GC is called.

The scheme follows  the example in section "Garbage collection" of

The problem is that:
 When an object is being loaded through an "sql" select stmt, GC is
then invoked to reclaim memory which will in turn call finalise
functions to store some objects into db.  At this moment, the db has
been locked by the select stmt, and the storing procedure fails.  The
problem is due to sqlite3 doesn't provide row level locks.  A simple
solution is to prevent GC from calling finalise functions whenever we
are loading an object into memory.

IMHO, providing a way to disable GC will help a lot in variant
situations.  The only side effect of misuse such a feature is out of
memory exception which does happen even GC is always enabled.


On 12/1/06, Richard Jones <> wrote:
> On Thu, Nov 30, 2006 at 04:07:51PM -0800, Neal Wang wrote:
> > Thanks for your help.  But your solution only work for a function
> > which allocates
> >  memory of fixed size. Unfortunately, the atomic function, which
> > cannot be interrupted by GC, read input data from external channels
> > and the memory needed to store the input data is not determined ahead.
> > The official interface of GC doesn't not provide a  way to stop GC. Is
> > there a backdoor such that we can use to stop GC?
> I can't see how this would work.  The minor heap is a fixed size (32K
> or something) and when this is used up, you _have_ to do a minor
> collection.
> Can you tell us what the problem is that you're trying to solve?
> I've only seen two cases where I'd want to stop the GC from running:
> (1) During quasi real-time operations (eg. a single frame in a game) --
> this can be solved by making the heap large enough and running the GC
> at scheduled points.  (2) When the heap is larger than physical RAM --
> this is solved using our 'Ancient' module.
> Rich.
> --
> Richard Jones, CTO Merjis Ltd.
> Merjis - web marketing and technology -
> Internet Marketing and AdWords courses - - NEW!
> Merjis blog - - NEW!