On Oct 30, 2008, at 11:48 AM, CUOQ Pascal - [EMAIL PROTECTED] wrote:
Warren Harris <[EMAIL PROTECTED]> 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
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
