caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "CUOQ Pascal" <Pascal.CUOQ@cea.fr>
To: <caml-list@yquem.inria.fr>
Subject: RE: understanding weak
Date: Thu, 30 Oct 2008 19:48:26 +0100	[thread overview]
Message-ID: <5EFD4D7AC6265F4D9D3A849CEA9219191AB114@LAXA.intra.cea.fr> (raw)
In-Reply-To: <20081030182019.EEBC5BBB7@yquem.inria.fr>

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]


Warren Harris <warren@metaweb.com> wrote:
> I'd like to understand better how ocaml's weak pointers operate. 

You will be interested in the following important article:
http://portal.acm.org/citation.cfm?id=1411308
:)
 
>First, although it doesn't seem to be specified in the documentation,  
>I assume that weak pointers will *not* be reclaimed (e.g. from a weak  
>hash table) if the program retains some other reference to the object.  

Exactly.

>My second question relates specifically to my application. I would  
>like to have a primary cache of objects, and a secondary index into  
>sub-objects referenced from the primary cache. I.e. CacheA references  
>objects of type A; objects of type A reference objects of type B;  
>CacheB references objects of type B. I would like to guarantee that  
>weak references in CacheB are not flushed unless the corresponding  
>reference from CacheA is first flushed. I assume will be the case if a  
>non-weak reference from A to B is maintained.

The non-weak reference from A to B prevents B being unreachable
without A being unreachable, so yes, a reference from CacheB can
not disappear without the reference from CacheA disappearing
earlier or simultaneously.
This said, if what you want is really a cache, you would probably be
better off fixing its size and renewal strategy yourself than letting
the GC do it for you (by using weak pointers). What it will do has almost
no chance of being the best compromise between memory use and
speed for your application, and it may change without notice from
one version to the other. In short: don't use weak pointers to make caches.

>Can anyone verify?

If you want to experiment to confirm your impressions, the function
Gc.full_major is your friend.

Pascal





[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3459 bytes --]

       reply	other threads:[~2008-10-30 18:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081030182019.EEBC5BBB7@yquem.inria.fr>
2008-10-30 18:48 ` CUOQ Pascal [this message]
2008-10-30 19:12   ` [Caml-list] " Daniel Bünzli
2008-10-30 19:35   ` Warren Harris
2008-10-30 23:06     ` Alain Frisch
2008-10-31  8:33       ` Rémi Vanicat
2008-11-01  1:08   ` [Caml-list] " Jon Harrop
2008-11-01 10:37     ` Stefano Zacchiroli
2008-11-01 15:18       ` kirillkh
2008-10-30 18:19 Warren Harris

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=5EFD4D7AC6265F4D9D3A849CEA9219191AB114@LAXA.intra.cea.fr \
    --to=pascal.cuoq@cea.fr \
    --cc=caml-list@yquem.inria.fr \
    /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).