[Pharo-project] Quasi-stateful traits?

Igor Stasenko siguctua at gmail.com
Fri Feb 26 18:39:51 EST 2010


One of the ways of introducing a stateful traits is changing the VM
object format.
There is a bits in object's header reserved for identity hash.
Instead of putting the identify hash value there, we could use it to
indicate if given object has additional arbitrary slots following the
object contents:

<header>
<ivar1>
...
<ivarN>
<variableVar1>
...
<variableVarM>
<key1><value1>
<key2><value2>
...
<keyK><valueK>

so, these keyN->valueN forming a dictionary of key/value pairs, which
can be accessed using new primitives #slotAt: and #sloatAt:put:

slot allocaiton can be expressed as:

newObject := object copyWithSlot: key value: value.
object becomeForward: newObject.

(except that this is done by VM primitively).

Once slots is allocated, object size is not grows anymore (so there
are no overhead) and as bonus, you getting a way to attach any
additional state to virtually any objects (except smallints) , for any
purposes.
Identity hash is become slower, but only at first hashing attempt.
(slotAt: #identityHash put: value)
But as benefit, we could use any object (or just 31 bit small integer)
for hash values, which will increase the hashing quality considerably.
So, it is a question, what will be faster, especially for large
dictionaries.

Obviously, then traits free to use this to keep own state, without any
extra demands from classes where it installed:

foo
  ^ self slotAt: #foo
foo: value
  self slotAt: #foo put: value

Also, I think that with such extension, we might expect a considerable
speed boost for Magma OODB, which can use additional slot for marking
objects by own ids, as well as for marking object dirty, instead of
maintaining a huge and ineffective IdentityDictionaries to track the
objects state.

-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list