Yet another changeset, different this time, need to apply to a fresh  
3.6 image, supersedes, does not
replace the earlier changeset.

This changeset  gets the hash at allocation time from a constant lookup  
table, we build the
4096 element table by issuing a shuffle on a 0-4095 interval then bit  
shift to get integers we just can
OR directly against a header without additional work.

I have run the JMMObjectMemory test routine to validate that the  
before/after allocation logic is the same.
In testing I find that heavy object allocation is 5-9% faster, but alas  
the difference is difficult to see in normal execution.

Not tested to see if the interpreter simulator change works.

Need someone to try on intel  or other less capable hardware to see if  
there is a improvement.

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AllocateNoFillHashTable-JMM.1.cs.gz
Type: application/x-gzip
Size: 10299 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030716/e9ca3291/AllocateNoFillHashTable-JMM.1.cs.bin