> From:   "Lex Spoon" < lex at c... >
> Date:   Fri Jul 11, 2003  8:06 pm
> ...

> The only cost of using the new-space-only approach is that there will  
> be
> tenured objects whose hash is not used but whose hash is computed
> anyway. This cost should be pretty low, because tenures don't happen
> very often under normal usage.
>
> There are a number of advantages:
>
> 1. All VM's work with all images. Period.
...

Ok, I build a VM with the faster allocation code, then tried using it,  
didn't seem to have any problems, then added in the no-hash logic
then I ran into problems for which I've spent most of the weekend  
debugging.

As a result I wrote a test procedure to check the old versus new   
allocation routines which iterates over all 393,216 combinations of the  
class type (2 bits in the hash field, 5 bits of compact class index, 4  
bits of object format, 6 bits of object size) with an additional range   
0-4 bytes for indexable size, plus of course a bit of fiddling to  
ensure object size never is zero. This showed one problem where the  
header1 bitAnd: 16r1FFFF logic in instantiateClass:indexableSize: was  
really needed to clear out the 2 bit class size from the classpointer  
information after I had zapped that line which was part of the original  
hash calculation.

Well I should have done this test procedure (shades of sunit testing)  
up front, but didn't, however now it's written and I can say the  
behaviour of allocation before/after tuning  is identical.


hashBitsOf: is also now called in

ObjectMemory>>restoreHeadersAfterBecoming: list1 with: list2
ObjectMemory>> restoreHeadersAfterForwardBecome

because hashbits are swapped in these places.
also of course the following two methods have always called hashBitsOf:
Interpreter>>lookupMethodInDictionary:
Interpreter>> primitiveAsOop

To fix up the identity hash bits in young space, I call the following  
routine from two locations
ObjectMemory>>computeIdentityHashForObjectsFrom: startOopAddr
	"Ensure we have valid hashs for objects in youngSpace"

	| oop |
	self inline: false.

	oop _ self oopFromChunk: startOopAddr.
	[oop = nil] whileFalse: [
		(self isIntegerObject: oop) ifFalse: [self hashBitsOf: oop].
		DoAssertionChecks ifTrue: [self okayFields: oop].
		oop _ self accessibleObjectAfter: oop.
	].

  vai incrementalGC only when we do the tenure, and from fullGC before  
we do the full GC with the
boundary still set to the original young space.

I'd welcome any other comments/suggestions to ensure identity hash bits  
of zero don't leak out of young space.

I couldn't get this all to work until this evening because of a  
misunderstanding of how to traverse from youngStart to endOfMemory by  
oops, versus memory address. I mistake on my part allowed the  
traversal, somewhat, enough to run things for a few minutes before  
locking up. That is fixed now I understand what I did wrong. I'll also  
thank the folks that did the AssertionChecks logic, that certainly  
helps ensure I've not bit twiddled a change that invites image  
corruption.

Right now I'm running the macrobenchmarks in a loop with  
doAssertionChecks on, with a forked 1 asFloat allocation routine  
running to stress the collectors.  I'll leave that run overnight just  
to be sure.  Then I'll report on performance statistics.


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