<br><br><div class="gmail_quote">On Mon, Jun 11, 2012 at 1:36 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Some extra ideas.<br>
<br>
1. Avoiding extra header for big sized objects.<br>
I not sure about this, but still ..<br>
<br>
according to Eliot's design:<br>
<div class="im">8: slot size (255 => extra header word with large size)<br>
<br>
</div>What if we extend size to 16 bits (so in total it will be 65536 slots)<br></blockquote><div><br></div><div>This simply doesn't make sense within the overall context of the header (i.e. relatively large identityHash the same size as the class index). A large size field increases the size of the header for all objects. An extra size word for large objects only increases the size (probably by 8 bytes) for large objects. But that's a very small percentage overhead of at most 8 / (256 * 4), or 0.8%. Few objects are large. The bulk of objects are smaller than 256 slots. Its a no-brainer; have a small size field and overflow only for large objects.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and we have a single flag, pointing how to calculate object size:<br>
<br>
flag(0) object size = (size field) * 8<br>
flag(1) object size = 2^ (slot field)<br>
<br>
which means that past 2^16 (or how many bits we dedicate to size field<br>
in header) all object sizes<br>
will be power of two.<br>
Since most of the objects will fit under 2^16, we don't lose much.<br>
For big arrays, we could have a special collection/array, which will<br>
store exact size in it's inst var (and we even don't need to care in<br>
cases of Sets/Dicts/OrderedCollections).<br>
Also we can actually make it transparent:<br>
<br>
Array class>>new: size<br>
size > (max exact size ) ifTrue: [ ^ ArrayWithBigSizeWhatever new: size ]<br>
<br>
of course, care must be taken for those variable classes which<br>
potentially can hold large amounts of bytes (like Bitmap).<br>
But i think code can be quickly adopted to this feature of VM, which<br>
will simply fail a #new: primitive<br>
if size is not power of two for sizes greater than max "exact size"<br>
which can fit into size field of header.<br>
----<br>
<br>
2. Slot for arbitrary properties.<br>
If you read carefully, Eliot said that for making lazy become it is<br>
necessary to always have some extra space per object, even if object<br>
don't have any fields:<br>
<div class="im"><br>
<<We shall probably keep the minimum object size at 16 bytes so that<br>
there is always room for a forwarding pointer. >><br>
<br>
</div>So, this fits quite well with idea of having slot for dynamic<br>
properties per object. What if instead of "extending object" when it<br>
requires extra properties slot, we just reserve the slot for<br>
properties at the very beginning:<br>
<br>
[ header ]<br>
[ properties slot]<br>
... rest of data ..<br>
<br>
so, any object will have that slot. And in case of lazy-become. we can<br>
use that slot for holding forwarding pointer. Voila.<br>
<br>
3. From 2. we going straight back to hash.. VM don't needs to know<br>
such a thing as object's hash, it has no semantic load inside VM, it<br>
just answers those bits by a single primitive.<br>
<br>
So, why it is kind of enforced inherent property of all objects in<br>
system? And why nobody asks, if we have that one, why we could not<br>
have more than one or as many as we want? This is my central question<br>
around idea of having per-object properties.<br>
Once VM will guarantee that any object can have at least one slot for<br>
storing object reference (property slot),<br>
then it is no longer needed for VM to care about identity hash.<br>
<br>
Because it can be implemented completely at language size. But most of<br>
all, we are NO longer limited<br>
how big/small hash values , which directly converts into bonuses: less<br>
hash collisions > more performance. Want 64-bit hash? 128-bit?<br>
Whatever you desire:<br>
<br>
Object>>identityHash<br>
^ self propertiesAt: #hash ifAbsentPut: [ HashGenerator newHashValue ]<br>
<br>
and once we could have per-object properties.. and lazy become, things<br>
like Magma will get a HUGE benefits straightly out of the box.<br>
Because look, lazy become, immutability - those two addressing many<br>
problems related to OODB implementation<br>
(i barely see other use cases, where immutability would be as useful<br>
as in cases of OODB)..<br>
so for me it is logical to have this last step: by adding arbitrary<br>
properties, OODB now can store the ID there.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>