<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 10:17 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Nov 14, 2014 at 9:20 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
On 14.11.2014, at 17:56, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
<br>
>>> Anyway, something to be aware of -- anywhere we have true, false or<br>
>>> nil used in a hash calculation, now has a different hash in Spur vs.<br>
>>> Cog. Maybe we should think about separating those objects' logical<br>
>>> "value" hash from their identityHash in trunk..? That could be useful<br>
>>> when we move to 64-bit someday..<br>
>><br>
>> Remember that Spur has a common header format for both 32-bit and 64-bit<br>
>> versions, so in both there is a 22-bit identityHash and hence the<br>
>> identityHashes of all objects in a 64-bit Spur image bootstrapped from a<br>
>> 32-bit Spur image will be _unchanged_. Convenient. So no need to worry.<br>
>> And it should be the case that a freshly bootstrapped 64-bit Spur image does<br>
>> not need to be rehashed to function properly.<br>
><br>
> Suprising that their identityHash needs to change for Spur<br>
<br>
</span>It didn't *have* to change. Eliot could have just re-used the old identity hash of nil, true, and false. He probably just didn't think to do that.<br></blockquote><div><br></div></span><div>Right. I thought since identityHashes would be changing (class identityHashes must change for Spur's class table, and there are more than 2^10 objects in an image) I would assign new hashes to all objects in the image that needed them and start with 1, 2 & 3 as the hashes for the first objects, nil, false & true. Any system which relies on identityHashes not changing from V3 to Spur will be broken anyway, so why keep the hashes for those objects?</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> but not to go to 64-bit..<br>
<br>
</span>Spur already increases the number of bits to 22. It does not increase it again for 64 bits. 4 M different hashes should be enough, just like 4 M possible classes should be enough ;)<br>
<span><br>
> Wait, I thought one of the benefits of 64-bit was to finally increase<br>
> that small identityHash?<br>
<br>
</span>22 > 10<br></blockquote><div><br></div></span><div>Right (see both Bert's & Levente's responses). Spur lifts the number of identityHashes from 2^10 to 2^22. There's no room for more in a 64-bit system. SPur is designed to go beyond 32-bits, but it isn't designed for terabyte heaps. One step at a time ;-)</div></div></div></div></blockquote><div><br></div><div>I should say no room for more hash bits in *this* 64-bit system. Here's the Sour object header:</div><div><br></div><div><div>headerForSlots: numSlots format: formatField classIndex: classIndex</div><div><span class="" style="white-space:pre"> </span><api></div><div><span class="" style="white-space:pre"> </span>"The header format in LSB is</div><div><span class="" style="white-space:pre"> </span> MSB:<span class="" style="white-space:pre"> </span>| 8: numSlots<span class="" style="white-space:pre"> </span>| (on a byte boundary)</div><div><span class="" style="white-space:pre"> </span>| 2 bits<span class="" style="white-space:pre"> </span>|<span class="" style="white-space:pre"> </span>(msb,lsb = {isMarked,?})</div><div><span class="" style="white-space:pre"> </span>| 22: identityHash<span class="" style="white-space:pre"> </span>| (on a word boundary)</div><div><span class="" style="white-space:pre"> </span>| 3 bits<span class="" style="white-space:pre"> </span>|<span class="" style="white-space:pre"> </span>(msb <-> lsb = {isGrey,isPinned,isRemembered}</div><div><span class="" style="white-space:pre"> </span>| 5: format<span class="" style="white-space:pre"> </span>| (on a byte boundary)</div><div><span class="" style="white-space:pre"> </span>| 2 bits<span class="" style="white-space:pre"> </span>|<span class="" style="white-space:pre"> </span>(msb,lsb = {isImmutable,?})</div><div><span class="" style="white-space:pre"> </span>| 22: classIndex<span class="" style="white-space:pre"> </span>| (on a word boundary) : LSB</div><div><span class="" style="white-space:pre"> </span> The remaining bits (7) are used for</div><div><span class="" style="white-space:pre"> </span>isImmutable<span style="white-space:pre"> </span><span class="" style="white-space:pre"> </span>(bit 23)</div><div><span class="" style="white-space:pre"> </span>isRemembered<span class="" style="white-space:pre"> </span>(bit 29)</div><div><span class="" style="white-space:pre"> </span>isPinned<span class="" style="white-space:pre"> </span><span style="white-space:pre"> </span>(bit 30)</div><div><span class="" style="white-space:pre"> </span>isGrey<span class="" style="white-space:pre"> </span>(bit 31)</div><div><span class="" style="white-space:pre"> </span>isMarked<span class="" style="white-space:pre"> </span><span style="white-space:pre"> </span>(bit 55)</div><div><span class="" style="white-space:pre"> </span> leaving 2 unused bits, each next to a 22-bit field, allowing those fields to be</div><div><span class="" style="white-space:pre"> </span> expanded to 23 bits.. The three bit field { isGrey, isPinned, isRemembered }</div><div><span class="" style="white-space:pre"> </span> is for bits that are never set in young objects. This allows the remembered</div><div><span class="" style="white-space:pre"> </span> table to be pruned when full by using these bits as a reference count of</div><div><span class="" style="white-space:pre"> </span> newSpace objects from the remembered table. Objects with a high count</div><div><span class="" style="white-space:pre"> </span> should be tenured to prune the remembered table."</div><div><span class="" style="white-space:pre"> </span><returnTypeC: #usqLong></div><div><span class="" style="white-space:pre"> </span><inline: true></div><div><span class="" style="white-space:pre"> </span>^ ((self cCoerceSimple: numSlots to: #usqLong) << self numSlotsFullShift)</div><div><span class="" style="white-space:pre"> </span>+ (formatField << self formatShift)</div><div><span class="" style="white-space:pre"> </span>+ classIndex</div></div><div><br></div><div>I hope this makes sense...</div></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>