<div dir="ltr"><div>Ah, a subject for Andres Valloud certainly...<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-21 16:25 GMT+01:00 Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>Currently, the identityHash of a SmallInteger is that value itself. The hash primitive (75) fails for SmallIntegers.<br>
<br>
For new immediate objects I think the VM needs to answer a hash, because it would be inconvenient/expensive to do on the image side.<br>
<br>
The VM could simply re-interpret the bits of the oops as if it was a SmallInteger. But it could also pick 22 bits (as for non-immediate objects) depending on the immediate class that are likely to make a good hash (*).<br>
<br>
If we do the latter, would it be possible to make the identityHash of boxed floats be the same?<br>
<br>
The advantage of this would be that the VM could freely demote a boxed float into an immediate one at any time, even if it was held in an identity dictionary. That way the image might not have to worry as much about normalizing floats (as it has to do now with large integers).<br>
<br>
- Bert -<br>
<br>
(*) For an immediate double, picking the lower 22 bits of the upper 32 bit word seems reasonable, taking the 2 least significant bits of exponent and 20 most significant bits of the mantissa.<br></blockquote></div><br></div>