English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: Ancient, concurrency, etc.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-05-11 (04:21)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Re: Ancient, concurrency, etc.
On Saturday 10 May 2008 10:09:04 Berke Durak wrote:
> On Sat, May 10, 2008 at 10:51 AM, Richard Jones <rich@annexia.org> wrote:
> > There are various restrictions on mutating the ancient data, which are
> > explained in the README.  It is not true that ancient data is
> > completely immutable, just that you really need to understand what
> > you're doing in order to do it correctly.
> I'm not talking of mutating atomic values here.

I assume Richard was referring to injecting references from the ancient heap 
into the live heap using mutation. If the value were later moved on the live 
heap then the OCaml run-time would not know to update the pointer in the 
ancient heap and you would get a dangling pointer.

> I'm saying that you certainly can't have the GC or someone else mutate the
> data for traversal purposes.

I believe the GC will never try to traverse it so it will not mutate it.

> > I'm not sure what this means.  I haven't tried to Marshal ancient
> > data, because ancient data can already be persisted, so marshaling it
> > doesn't make much sense.
> > 'Deep copying' of ancient data can be done just like deep copying any
> > other OCaml value.
> As in: it can't be done polymorphically, unless you resort to Marshal,
> which doesn't work on ancient data.

Or memcpy.

> > because they make the assumption that anything outside the normal
> > OCaml heap is incomparable
> And that can be quite annoying, so we'd like a way to take values of out
> the ancient heap.

This is exactly the incidental complexity I was referring to.

> > , but you can certainly write your own
> > comparison functions to replace those, eg. comparing
> > character-by-character for strings.
> Not. Polymorphic.

Use memcmp. :-)

> > This has nothing to do with 'marking'.
> Well, walking over a value graph, either for complete
> hashing/comparison/copying or
> serialization requires marking unless your graph is a tree.

Not really. There are two problems here. Firstly, OCaml's built in hashing, 
comparison and equality blindly recurse without checking for cycles so they 
do not need any metadata. Secondly, you can store the traversal data outside 
the graph: there is no need to mark it.

> > So it seems that adding a generic copy-out-of-the-ancient heap function
> >
> > > (which marks in a private area) would be worthwhile.  Should not be too
> > > difficult.
> >
> > As I said earlier, you can just copy values from the ancient heap as
> > you would any other value, eg. using { ... with ... } syntax or
> > Array.copy / String.copy etc.
> That is not polymorphic.

If we have a type:

  type t = { x: float; n: int }

with a value of that type in the ancient heap and we do:

  let local = { ancient with n=3 }

then we have created a shallow copy that has now pulled a pointer to the boxed 
float value in the ancient heap into our GC which will later try to 
deallocate that float and crash. Is that correct?

Dr Jon D Harrop, Flying Frog Consultancy Ltd.