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
[Caml-list] Marshalling objects (was: French interactive fiction, anyone ?)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-06-20 (14:39)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] Marshalling objects (was: French interactive fiction, anyone ?)
Great, an implementer's discussion on the Caml list!
Where is Jerome ?!

From: Xavier Leroy <>
> > > since Caml can save closures under
> > > the same constraints, the reason why objects can't be saved must be
> > > something else.
> > 
> > Actually I cannot remember any such reason.
> > I actually tried, just commenting out the Object_tag case in
> > byterun/extern.c, and it works!
> I'm always suspicious about "it works!" claims :-)

The bang expressed an experimental truth, which can be reverted by
other experiments :-)

> IIRC, one of the potential issues here is that methods are numbered at
> program start-up time, via the Oo.new_method support function.  The
> numbering of methods, then, determines the layout of vtables.  With
> your solution, you're saving and reloading the vtable of the object as
> a normal data structure.  This is correct only if the program that
> saves the object and the program that reads it assign the same numbers
> to methods.

After a deeper look at -dlambda and, this holds, but only as
long as you're not using let modules.  That is, public labels are
correctly lifted to the toplevel, but private labels may be generated
at class initialization. Since classes are toplevel structures inside
modules, class initializations occur in a fixed order as long as there
are no let modules.
But even that is easy to fix: private labels are local to a class, and
they need not be kept between runs. However public labels must not
change. The current scheme has one single counter for both kinds of
labels, but it should be easy to use two counters, putting public and
private methods in different buckets.

> Another potential issue is the un-sharing of vtables: in the present
> system, all instances of a class share a common vtable; this is no
> longer true with your marshaling/unmarshaling scheme.  Again, this
> doesn't seem to break anything, but I'd like to be certain that
> pointer equality on vtables is nowhere used.

It's not a scheme, it's inaction...
I should look more carefully, but I don't see any point in using pointer
equality on vtables, except for some kind of unspecified reflection.
Note that it does not guarantee type equality, as classes may be

> > There's a single glitch: as it just handles objects as normal data,
> > oid's are not updated. This means that equality on objects (which is
> > oid based) will be incorrect.
> This issue could be addressed by special-casing Object_tag in input_value,
> and making the OID counter available from C.

Yes, the only subtlety is that the counter is on the caml side, so you
need a callback for that.

> > On the other hand, objects are not just closures, and it would be nice
> > to be able to serialize their data in a code-independent way. Not so
> > unreasonable: class names are unique.
> Methinks you're confusing Caml with Java :-)  What kind of unique
> class names do you have in mind?

Since a class definition also defines a type, module semantics say that
every class name is unique inside its module. From that I thought we
could get the same thing as exception names: use the path. But maybe I
overlooked something?
Note that let modules would be a problem though.

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: