object system...
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- Date: Tue, 6 Jan 2009 01:08:54 +1000
well, anyways, I am back on usenet again as I have managed to locate a
working server. I have been away from usenet for a fairly long time,
basically since the server with my ISP died and I had no other working
server, it was either google groups or nothing, and I just didn't bother
much.
but, oh well, I figure I will present some of the ideas behind an object
system I had implemented and am making use of in my projects, and maybe
people can comment if some things are good or not so good.
basically, the core of the system is this:
Single-Inheritance Class/Instance OO (MI is more-or-less supported as well,
but it is hacky and not well supported by the APIs, so I mostly ignore MI);
there are Interfaces, like in Java and friends;
....
but, it differs from the normal model some in a few ways:
interfaces can implement slots as well as methods;
it is technically possible to use any interface with any compatible class
(due to a side effect of how the interface mechanism is implemented, the
same interface will work on a class regardless of whether or not said class
implements the interface as such);
it is possible to modify class layout at runtime, and the object system
machinery will work to keep everything consistent (internally, a versioning
system is used, so an older object may be layed out according to an older
version of the class), however doing so will reduce the performance of the
class(es) in question;
it is possible to add slots to individual instances of an object, allowing
the emulation of some aspects of Prototype-OO style (as well as the ability
to "clone" objects, ...), however, these slots will perform worse than those
defined in the class, and in general there are some restrictions placed on
these slots (it is only possible to access them either by name-based access,
special functions, or through the use of interfaces which contain the slot
in question);
there is also support for object delegation (like in Self or JavaScript),
but this feature can at present only be used via interfaces (this is mostly
for technical reasons);
there is also support for special assignable methods, which exist in the
instance rather than in the class (the method is actually directed through a
slot rather than through the vtable).
so, in short, for many tasks it is necessary to make use of an interface
rather than the direct physical class (but, as a cost, accessing a slot or a
method via an interface is slower than accessing it directly).
I did check before, but with my model it is possible to make use of many of
these features while still being within the realm of what could be
statically proven to be correct (although keeping things statically provable
would place many other restrictions on everything as well, for example,
placing restrictions on which objects can be assigned to which interfaces,
either by requiring the class to 'implement' the interface, or by validating
that the class is compatible with the interface, ...).
there are currently 2 major ways this object system is in use in my case:
it is used as the object system within other pieces of code (for example, a
custom-written JVM);
it is used in C code via an API (the API in general could be loosely
compared with JNI, although there is no context structure, and the interface
is IMO a little cleaner);
....
actually, the API calls are used enough that as of yet I have not added OO
extensions as-such to my C compiler (using a plain C-based API keeps the
system easily usable from code compiled in GCC and similar).
performance could be better, but it is still "acceptable"...
performance with profile and debug:
accessing a slot by name takes 345ns (~863 clocks);
accessing a slot via a handle takes about 56ns (~140 clocks);
looking up a slot (and succeeding) takes 272ns;
failing a slot lookup takes 292ns.
calling a method via a name and signature takes 1059ns;
calling a virtual method via a handle tales 685ns;
calling a method via an interface handle takes 850ns.
tried compiling with compiler profile and debug turned off:
accessing a slot by name takes 94ns (~235 clocks);
accessing a slot via a handle takes about 13ns (32.5 clocks);
looking up a slot (and succeeding) takes 80ns;
failing a slot lookup takes 90ns.
calling a method via a name and signature takes 342ns (855 clocks);
calling a virtual method via a handle tales 253ns;
calling a method via an interface handle takes 312ns.
the performance on x86-64 is a bit worse (~30% in most cases, but up to
about 3x slower when looking things up by name...).
technically, nearly the entire object system is written in C, and in general
I compile my stuff with profile and debug options.
note that a major central structure in the object system is a few large hash
tables, which are the primary means by which things like interface lookups,
.... are performed (hashes are computed using the classname, slot/method
name, and method signature, ...).
or such...
.
- Follow-Ups:
- Re: object system...
- From: Dmitry A. Kazakov
- Re: object system...
- From: H. S. Lahman
- Re: object system...
- Prev by Date: Re: What is it?
- Next by Date: Re: please answer these questions as soon as possible. because i have exam
- Previous by thread: please answer these questions as soon as possible. because i have exam
- Next by thread: Re: object system...
- Index(es):
Relevant Pages
|
