caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* RE: understanding weak
       [not found] <20081030182019.EEBC5BBB7@yquem.inria.fr>
@ 2008-10-30 18:48 ` CUOQ Pascal
  2008-10-30 19:12   ` [Caml-list] " Daniel Bünzli
                     ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: CUOQ Pascal @ 2008-10-30 18:48 UTC (permalink / raw)
  To: caml-list

[-- 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 --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Caml-list] RE: understanding weak
  2008-10-30 18:48 ` understanding weak CUOQ Pascal
@ 2008-10-30 19:12   ` Daniel Bünzli
  2008-10-30 19:35   ` Warren Harris
  2008-11-01  1:08   ` [Caml-list] " Jon Harrop
  2 siblings, 0 replies; 8+ messages in thread
From: Daniel Bünzli @ 2008-10-30 19:12 UTC (permalink / raw)
  To: OCaml Mailing List


Le 30 oct. 08 à 19:48, CUOQ Pascal a écrit :

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

The documentation should be fixed, as it really doesn't make that  
point clear. It says "A weak pointer is a value that the garbage  
collector may erase at any time" and this isn't what you want if you  
are looking for weak references.

Best,

Daniel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Caml-list] RE: understanding weak
  2008-10-30 18:48 ` understanding weak CUOQ Pascal
  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-11-01  1:08   ` [Caml-list] " Jon Harrop
  2 siblings, 1 reply; 8+ messages in thread
From: Warren Harris @ 2008-10-30 19:35 UTC (permalink / raw)
  To: CUOQ Pascal - Pascal.CUOQ@cea.fr; +Cc: caml-list


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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Caml-list] RE: understanding weak
  2008-10-30 19:35   ` Warren Harris
@ 2008-10-30 23:06     ` Alain Frisch
  2008-10-31  8:33       ` Rémi Vanicat
  0 siblings, 1 reply; 8+ messages in thread
From: Alain Frisch @ 2008-10-30 23:06 UTC (permalink / raw)
  To: Warren Harris; +Cc: caml-list

Warren Harris wrote:
> On Oct 30, 2008, at 11:48 AM, CUOQ Pascal - Pascal.CUOQ@cea.fr wrote:
>> 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.

Although there is some similarity between a weak table and a cache 
("store values, but feel free to get rid of them"), they are really 
different beasts: a good implementation of a weak table should release 
memory as soon as possible to avoid memory leak; a good implementation 
of a cache should instead keep data as long as possible (until there is 
a good reason to release it, like resource exhaustion). In particular, 
data stored in a OCaml weak table will be released during the next 
collection cycle when it is no longer referenced by any strong 
reference; this is probably not what you expect from a cache!

-- Alain


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: understanding weak
  2008-10-30 23:06     ` Alain Frisch
@ 2008-10-31  8:33       ` Rémi Vanicat
  0 siblings, 0 replies; 8+ messages in thread
From: Rémi Vanicat @ 2008-10-31  8:33 UTC (permalink / raw)
  To: caml-list

Alain Frisch <alain@frisch.fr> writes:

> Warren Harris wrote:
>> On Oct 30, 2008, at 11:48 AM, CUOQ Pascal - Pascal.CUOQ@cea.fr wrote:
>>> 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.
>
> Although there is some similarity between a weak table and a cache
> ("store values, but feel free to get rid of them"), they are really
> different beasts: a good implementation of a weak table should release
> memory as soon as possible to avoid memory leak; a good implementation
> of a cache should instead keep data as long as possible (until there
> is a good reason to release it, like resource exhaustion).

It's true, but it could be interesting to have a cache pointer/cache
table provided with the garbage collector: it's the GC that know when
there is not enough memory left, and that it should free those cache
pointer to have some.

-- 
Rémi Vanicat


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Caml-list] RE: understanding weak
  2008-10-30 18:48 ` understanding weak CUOQ Pascal
  2008-10-30 19:12   ` [Caml-list] " Daniel Bünzli
  2008-10-30 19:35   ` Warren Harris
@ 2008-11-01  1:08   ` Jon Harrop
  2008-11-01 10:37     ` Stefano Zacchiroli
  2 siblings, 1 reply; 8+ messages in thread
From: Jon Harrop @ 2008-11-01  1:08 UTC (permalink / raw)
  To: caml-list

On Thursday 30 October 2008 18:48:26 CUOQ Pascal 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

Is this freely available anywhere?

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Caml-list] RE: understanding weak
  2008-11-01  1:08   ` [Caml-list] " Jon Harrop
@ 2008-11-01 10:37     ` Stefano Zacchiroli
  2008-11-01 15:18       ` kirillkh
  0 siblings, 1 reply; 8+ messages in thread
From: Stefano Zacchiroli @ 2008-11-01 10:37 UTC (permalink / raw)
  To: caml-list

On Sat, Nov 01, 2008 at 01:08:17AM +0000, Jon Harrop wrote:
> > You will be interested in the following important article:
> > http://portal.acm.org/citation.cfm?id=1411308
> Is this freely available anywhere?

<rant>

Seriously, you SPAM everybody here with periodical announces of
non-free issues of the OCaml journal and don't even have access to a
random lab with an ACM subscription?

</rant>

SCNR.

Do as we all do: look on authors' homepage, mail them, try citeseer
cache, ...

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right
uno zaino        -- A.Bergonzoni \__/ keys at the right time -- J.S.Bach


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Caml-list] RE: understanding weak
  2008-11-01 10:37     ` Stefano Zacchiroli
@ 2008-11-01 15:18       ` kirillkh
  0 siblings, 0 replies; 8+ messages in thread
From: kirillkh @ 2008-11-01 15:18 UTC (permalink / raw)
  To: Stefano Zacchiroli; +Cc: caml-list

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

On Sat, Nov 1, 2008 at 12:37 PM, Stefano Zacchiroli <zack@upsilon.cc> wrote:

> On Sat, Nov 01, 2008 at 01:08:17AM +0000, Jon Harrop wrote:
> > > You will be interested in the following important article:
> > > http://portal.acm.org/citation.cfm?id=1411308
> > Is this freely available anywhere?
>
> <rant>
>
> Seriously, you SPAM everybody here with periodical announces of
> non-free issues of the OCaml journal and don't even have access to a
> random lab with an ACM subscription?


I think the difference is that ACM is about science and Jon's journal is not
(AFAIK). And since I think science should be free, I'm on Jon's side here,
though I agree that spamming is not nice.

Do as we all do: look on authors' homepage, mail them, try citeseer
> cache, ...


Would be easier, if everyone just published citeseer or direct links.

-Kirill

[-- Attachment #2: Type: text/html, Size: 1420 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-11-01 15:19 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20081030182019.EEBC5BBB7@yquem.inria.fr>
2008-10-30 18:48 ` understanding weak CUOQ Pascal
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

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