Representation of objects

Representation of objects

[Nathaniel Gray]

I've been poking around a bit into the representation of objects in
OCaml and I'm a bit confused.  Based on caml_get_public_method in
asmrun/obj.c and various bits of stdlib/camlinternalOO.ml I see that
the method table is an "array" where the even entries are closures and
the odd entries "tags" -- hashed method names.  (The first two entries
are special.)  The table is stored sorted in order of increasing tag
value.  Please correct me if I've misunderstood something here.

I've got two questions:

1.  Does this mean that essentially all method invocations need to
search the method table?  The method table of a superclass is no
longer a prefix of that of a subclass.  There's a GETMETHOD(i,obj)
bytecode, but I'm struggling to figure out when you could use it.

2.  What about hash collisions?  There's no collision resolution code
in the method lookup functions.

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

Re: [Caml-list] Representation of objects

[Jacques Garrigue]

From: Nathaniel Gray <n8gray@gmail.com>

> I've been poking around a bit into the representation of objects in
> OCaml and I'm a bit confused.  Based on caml_get_public_method in
> asmrun/obj.c and various bits of stdlib/camlinternalOO.ml I see that
> the method table is an "array" where the even entries are closures and
> the odd entries "tags" -- hashed method names.  (The first two entries
> are special.)  The table is stored sorted in order of increasing tag
> value.  Please correct me if I've misunderstood something here.

Correct.

> I've got two questions:
> 
> 1.  Does this mean that essentially all method invocations need to
> search the method table?  The method table of a superclass is no
> longer a prefix of that of a subclass.  There's a GETMETHOD(i,obj)
> bytecode, but I'm struggling to figure out when you could use it.

>From other posts, it seems that you have found caml_get_public_method.

> 2.  What about hash collisions?  There's no collision resolution code
> in the method lookup functions.

The type system prevents them. That is, if there is a potential
collision between tag names, it will be detected at compile time.

Jacques Garrigue

Re: [Caml-list] Representation of objects

[Nathaniel Gray]

On 8/16/05, Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> wrote:
> From: Nathaniel Gray <n8gray@gmail.com>
> 
> > I've got two questions:
> >
> > 1.  Does this mean that essentially all method invocations need to
> > search the method table?  The method table of a superclass is no
> > longer a prefix of that of a subclass.  There's a GETMETHOD(i,obj)
> > bytecode, but I'm struggling to figure out when you could use it.
> 
> From other posts, it seems that you have found caml_get_public_method.

I have, but my question is whether or not this search is necessary on
every method call everywhere.  It seems like it probably is, but
perhaps there's something I haven't considered.  I'm basically trying
to figure out how clever the compiler is.

> > 2.  What about hash collisions?  There's no collision resolution code
> > in the method lookup functions.
> 
> The type system prevents them. That is, if there is a potential
> collision between tag names, it will be detected at compile time.

Ok, I see.

Thanks,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->