<br><br><div class="gmail_quote">On Thu, Jan 6, 2011 at 6:33 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><br><div class="gmail_quote">On Thu, Jan 6, 2011 at 6:23 AM, Mariano Martinez Peck <span dir="ltr"><<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>Hi folks. I am trying to understand a little how hash is assigned and how it works in the SqueakVM. I have a couple of questions:<br><br>1) There are 12 bits in the ObjectHeader for the hash. I saw that the value of this hash comes from #newObjectHash. But....this method answers a hash of 16 bit:<br>
newObjectHash<br> "Answer a new 16-bit pseudo-random number for use as an identity hash."<br><br> lastHash := 13849 + (27181 * lastHash) bitAnd: 65535.<br> ^ lastHash<br><br>Since in the OH we have 12 bits, each place where this method is used, then we have to do something like this:<br>
<br>header1 := (classFormat bitAnd: 16r1FF00) bitOr: (hash << HashBitsOffset bitAnd: HashBits).<br><br>or<br><br> hash := self newObjectHash.<br> header := (self longAt: newOop) bitAnd: 16r1FFFF.<br> "use old ccIndex, format, size, and header-type fields"<br>
header := header bitOr: ((hash << 17) bitAnd: 16r1FFE0000).<br><br>....<br>so, we always need to trim it to 12 bits using (hash << HashBitsOffset bitAnd: HashBits).<br><br>Now, I wonder, why #newObjectHash does not answer a 12bits long hash directly ? is it because of the hash function performance? <br>
<br><br>2) It looks to me that not, but can it change the hash of an object? if true, why and where?<br><br>3) If #basicIdentityHash is ONLY used for Sets and friends, why not letting the hash assignment as late/lazy as possible? i mean, instead of creating and assigning a hash at object creation, what if we do this in #hashBitsOf: oop <br>
where we can check in the hash is empty and if true assign one. <br>Would this make sense or it would be worst?<br></blockquote><div><br></div><div>IMO it is far better and I will implement this in the new object representation. VW has always had lazy hash creation.</div>
<div><br></div></div></blockquote><div><br>Excellent. Marcus told me about this :)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div></div><div>Note in Cog the hash is derived from the allocation pointer not from the pseudo-random hash generator, avoiding a read-modify-write cycle in object allocation.</div><div><br></div>
</div></blockquote><div><br>Yeah, I saw it:<br><br>newObjectHash<br> "Derive the new object hash from the allocation pointer. This is less costly than<br> using lastHash because it avoids the read-modify-write cycle to update lastHash.<br>
Since the size of eden is a power of two and larger than the hash range this provides<br> a well-distributed and fairly random set of values."<br> <inline: true><br> ^freeStart >> BytesPerWord<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div></div><div>best</div><div>Eliot</div>
<div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>Thanks<br><br>Mariano<br>
<br></blockquote></div><br>
<br></blockquote></div><br>