caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: matt@gushee.net
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Weak hashtables & aggressive caching
Date: Wed, 16 Aug 2006 09:54:49 +0900 (JST)	[thread overview]
Message-ID: <20060816.095449.21360713.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <44E10783.5000605@gushee.net>

From: Matt Gushee <matt@gushee.net>
> > I wonder how you trigger the GC, to both keep the cache long enough,
> > and to avoid filling the memory too much, and resulting in lots of
> > swapping.
> 
> I wasn't planning to trigger the GC explicitly. My thought was simply to 
> stop preloading before GC begins (or at least *when* GC begins).

But, if you wait for the GC to begin this is too late: all your weak
references will be collected as garbage, so that your cache will be
emptied as soon as you fill it.

> > means that the memory set should not increase. But with external data
> > structures like pixbufs, the GC is called in a pre-programmed way,
> > currently at least after every 10 pixbuf allocations.
> 
> You mean that LablGTK directly invokes the garbage collector after 10 
> images. That's not much (unless, of course, they are big images). Sounds 
> like it's a lot of trouble for a small benefit.

Again, the trouble is that there is only one allocation function for
pixbufs, and it doesn't look at their size. And it isn't aware of how
much memory is available either. So the choice was to be extremely
conservative. This is maybe a bad idea, but the intent is to avoid
keeping big garbage around, as I have seen really bad situations in
the past (programs growing to more than 100MB pretty fast.) Since weak
references are counted as garbage, there is clearly a contradiction.

I suppose more GC tuning in lablgtk would be a good thing. But I
really don't see how to do it easily with the ocaml allocation API.
The only way to interface external allocation with the GC is an
increment N you pass when calling alloc_custom. It tells ocaml to
shorten the time to next GC by N % (actually this is a ratio, so you
can provide smaller increments.) The trouble is that the GC is
triggered by the sum of all increments for all allocations. So if you
want to slow it, you need to reduce all increments everywhere...

Jacques Garrigue


  reply	other threads:[~2006-08-16  1:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-14 14:58 Matt Gushee
2006-08-14 15:47 ` [Caml-list] " Richard Jones
2006-08-14 16:28   ` Matt Gushee
     [not found]     ` <44E0A8F1.8060504@janestcapital.com>
2006-08-14 17:35       ` Matt Gushee
2006-08-14 18:18     ` Richard Jones
2006-08-14 23:25       ` Matt Gushee
2006-08-14 21:23 ` Jacques Garrigue
2006-08-14 23:30   ` Matt Gushee
2006-08-16  0:54     ` Jacques Garrigue [this message]
2006-08-16  4:33       ` Matt Gushee
2006-08-15  4:55   ` skaller
2006-08-15 16:17     ` Matt Gushee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060816.095449.21360713.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=matt@gushee.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).