On Mon, Jul 22, 2019 at 03:16:02PM -0700, tim Rowledge wrote:
> OK, so after fun doing a binary split, I can now assert that loading
> Kernel-eem.1198.mcz is what breaks the compilation of that particular
> method. That's the change where Eliot altered the hashing to make things
> be the same between 32 & 64 bit systems. On a 32bit Pi we clearly get
> a value beyond SmallInteger range with the new version of LPI>>hash.
> Reverting the change to LPI>>hash makes it possible to compile the
> problematic method. 
> 

I can't think of any reason that it would be a problem, but note that
on 32 bit Spur images:

  1073741824 hash class ==> LargePositiveInteger

And on 64 bit Spur images:

  1073741824 hash class ==> SmallInteger

So the values of the hash values are the same on 32 bit and 64 bit images,
but the classes of the hash values can be different.

> I'm actually having a bit of a hard time working out how it can cause
> a complete lock up of the image though. Is it some issue with a 32bit
> VM not liking non-SmallInt hash values? Maybe some related prim that
> only accepts machine/vm word sized values?
> 

I don't know the answer (and I am fairly clueless with regard to hashing),
but is there some general expectation that the hash value for an object
should fall within the range of small integers?

Prior to Kernel-eem.1198, I think it was true that all integers had
hash values that were small integers, and that now we have a certain
range of integers which, on 32-bit images, have hash values that are
LargePositiveInteger. I don't know why that would be a problem, but
maybe it is?

Dave