Class runtime representation

Class runtime representation

[Dmitry Bely]

Just curious: why Ocaml runtime should know class method names? Why
the method tag (a hash value computed from the name) is not enough?

- Dmitry Bely

Re: [Caml-list] Class runtime representation

[Till Varoquaux]

I would conjecture it needs the full name in case of collision, but
someone better informed than me will probably give you the definite
answer.

Till

On Dec 7, 2007 8:59 AM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
> Just curious: why Ocaml runtime should know class method names? Why
> the method tag (a hash value computed from the name) is not enough?
>
> - Dmitry Bely
>
> _______________________________________________
> 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
>



-- 
http://till-varoquaux.blogspot.com/

Re: [Caml-list] Class runtime representation

[Dmitry Bely]

On Dec 7, 2007 5:36 PM, Till Varoquaux <till.varoquaux@gmail.com> wrote:

> I would conjecture it needs the full name in case of collision, but
> someone better informed than me will probably give you the definite
> answer.

No, it's detected during compilation:

class test =
object
  method argzad = 1
  method ctzakz = 2 (* the same hash value *)
end

ocamlopt -c test.ml
File "test.ml", line 2, characters 0-53:
Method labels `ctzakz' and `argzad' are incompatible.
Change one of them.

When you invoke a method the name is not involved (only the label is).

- Dmitry Bely

Re: [Caml-list] Class runtime representation

[Jacques Garrigue]

From: "Dmitry Bely" <dmitry.bely@gmail.com>
> Just curious: why Ocaml runtime should know class method names? Why
> the method tag (a hash value computed from the name) is not enough?

Good question.
Names are only used during class construction, which is dynamic in
ocaml. Names are used for methods (both public and private) and
instance variables. Of all those, only public methods use a hashed
values in other operations, and for this reason public methods in the
same class are guaranteed to have no hash conflicts. But this is not
enforced for private methods, which can always be called in a more
direct way. And since some internal data structures mix private and
public methods, it seems simpler to have names for all.

Now, as we can also statically detect potential conflicts between
private methods, it would be possible to use hashed tags for private
methods too (and even instance variables). This might improve code
size, as names would disappear from the runtime. This would not change
performance however, as class construction only occurs once for most
class declarations, and a fixed number of times in more complex
examples combining inheritance and functors. And it would introduce a
new restriction on the naming of private methods.

Another reason names were kept is to eventually allow runtime
introspection. This is not accessible currently, but the runtime knows
the names of all methods in a class.

Jacques Garrigue

Re: [Caml-list] Class runtime representation

[Dmitry Bely]

On Dec 8, 2007 4:36 PM, Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> wrote:

> Names are only used during class construction, which is dynamic in
> ocaml. Names are used for methods (both public and private) and
> instance variables. Of all those, only public methods use a hashed
> values in other operations, and for this reason public methods in the
> same class are guaranteed to have no hash conflicts. But this is not
> enforced for private methods, which can always be called in a more
> direct way. And since some internal data structures mix private and
> public methods, it seems simpler to have names for all.
>
> Now, as we can also statically detect potential conflicts between
> private methods, it would be possible to use hashed tags for private
> methods too (and even instance variables). This might improve code
> size, as names would disappear from the runtime. This would not change
> performance however, as class construction only occurs once for most
> class declarations, and a fixed number of times in more complex
> examples combining inheritance and functors. And it would introduce a
> new restriction on the naming of private methods.

Thanks for the detailed explanation. I don't like method names in the
binary because they show some implementation details that I would like
to hide; several extra bytes of code are really not a problem.

- Dmitry Bely

Re: [Caml-list] Class runtime representation

[Richard Jones]

On Mon, Dec 10, 2007 at 05:00:41PM +0300, Dmitry Bely wrote:
> Thanks for the detailed explanation. I don't like method names in the
> binary because they show some implementation details that I would like
> to hide; several extra bytes of code are really not a problem.

I suppose you could preprocess the source to mangle method names, but
to be honest if you're worried about the security of the binary from
reverse engineering I'm afraid that you'll need to consider a lot more
than just mangling.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Class runtime representation

[Dmitry Bely]

On Dec 10, 2007 6:51 PM, Richard Jones <rich@annexia.org> wrote:

> > Thanks for the detailed explanation. I don't like method names in the
> > binary because they show some implementation details that I would like
> > to hide; several extra bytes of code are really not a problem.
>
> I suppose you could preprocess the source to mangle method names,

Writing such "obfuscator" may be non-trivial.. I tend to think that
modifying Ocaml compiler can be simpler.

> but
> to be honest if you're worried about the security of the binary from
> reverse engineering I'm afraid that you'll need to consider a lot more
> than just mangling.

Not that I worry about reverse engineering too much, but my manager is
not very happy to see human-readable method names in the binary (I
spent enough time to get a permission to code anything in Ocaml; I
don't like to lose it eventually)

- Dmitry Bely