Re: [Caml-list] RE: understanding weak

[Warren Harris <warrensomebody@gmail.com>]

On Oct 30, 2008, at 11:48 AM, CUOQ Pascal - Pascal.CUOQ@cea.fr wrote:

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

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

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

Warren