>> From:   "Andreas Raab" < andreas.raab at g... >
>> Date:   Wed Jul 16, 2003  9:31 pm
>> Subject:   RE: [ENH][VM] HashBits, a lazy way
>>
>>
>> ADVERTISEMENT
>>
>> 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
>>


Ah, it's a changeset collision, which triggers a C array boundary  
issue. Which is why I hate C

ObjectMemory class>declareCVarsIn:

...
	aCCodeGenerator
		var: #headerTypeBytes
		declareC: 'int headerTypeBytes[4]'.   <---- See the bug?


That should be 4+1, not 4, if in fact you have not applied my earlier  
changeset BitOfGCTuning-JMM.5.cs

We make a 4 element array then index with [4]. Heh heh, might work,  
wonder what is in that memory location.  Of course headerTypeBytes is  
used in lots of places, certainly doing this code in the readimage logic

	headerTypeBytes at: 1 put: 8. "3-word header (type 0)"	
	headerTypeBytes at: 2 put: 4. "2-word header (type 1)"
	headerTypeBytes at: 3 put: 0. "free chunk (type 2)"	
	headerTypeBytes at: 4 put: 0. "1-word header (type 3)"

like we do will cause a memory side effect...

Now what I did is take the 5325 image from the server, update from the  
network to 3.6a 5352, then update all
the installed SM stuff, then installed VMMaker, then updated that map  
then applied my  one earlier changeset, then fixed my changeset  
collision by ensuring headerTypeBytes is 5 elements, make VM,  
compile,gnuify,etc?


Or of course you can go to interp.c and change

headerTypeBytes[4] to headerTypeBytes[5]

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===