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
RE: understanding weak
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-10-30 (19:35)
From: Warren Harris <warrensomebody@g...>
Subject: Re: [Caml-list] RE: understanding weak

On Oct 30, 2008, at 11:48 AM, CUOQ Pascal - wrote:

> Warren Harris <> wrote:
>> I'd like to understand better how ocaml's weak pointers operate.
> You will be interested in the following important article:
> :)

Thank you for the reference. Looks like the paper's timing couldn't be  

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

Thanks for the advice -- but I thought this was exactly what weak hash  
tables were intended for. (The paper seems to indicate that too.) I  
realize that an explicit replacement policy can be more application- 
friendly, but if what you really want is just "unless  anyone is using  
this" then using weak hash tables would seem appropriate.

>> Can anyone verify?
> If you want to experiment to confirm your impressions, the function
> Gc.full_major is your friend.

I'd hate to do an empirical analysis of this only to find I hadn't  
uncovered the full truth once the app was in production... so asking  
seemed like the way to go. Seems like the manual should say more here.