Hi John,

Something's wrong with these changes. When I build a VM with them in it
quits immediately, saying:


sweep failed to find exact end of memory

282656048 SystemDictionary>lowSpaceWatcher
282656344 [] in SystemDictionary>installLowSpaceWatcher
282656436 [] in BlockContext>newProcess
282656048 SystemDictionary>lowSpaceWatcher
282656344 [] in SystemDictionary>installLowSpaceWatcher
282656436 [] in BlockContext>newProcess

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of John M McIntosh
> Sent: Wednesday, July 16, 2003 11:06 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: [ENH][VM] HashBits, a lazy way 
> 
> 
> 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
> 
> ==============================================================
> ========== 
> ===
>