Attached is the changeset to:

a) Defer creating the identity hash until it is actually  needed by  
someone calling the identity hash primitive.   This removes it from  
clone:, instantiate class and instantiate small class.

b) Cleanup of the small class allocation, and instantiate class  
allocation logic to streamline the process.

c) no fill of most small class objects (Points,float, context, etc)  
Plus some other objects we immediate fill with data, such as the VM  
clipboard, vmparms, vm image name, etc...

d) A test class to iterate over the possible (I think) set of  
allocation requests to ensure before/after correctness.

This change set improves the allocation rate {based on allocating 50  
objects in a loop}.

1 asFloat, which now avoids generating a hash, and filling the object  
with zero bits before filling with the data.
before 3.5.2b1 -> 133,153 allocations per second, versus now ->   
150,459 per second. 13% better.

2 at 3
before 3.5.2b1 -> 165,856, after -> 183,413. 11% better

Array new: 4, which now avoids generating a hash, plus a bit of  
streamlining.
before 3.5.2b1 -> 129,045, versus new 138,067 per second, 7% better.

VM folks should check all this to see if there is some issue I've  
overlooked asking the questions...

a) Are the calls where we allocate small class objects with no-fill,  
viable, and not likely to raise a core dump because
of bad pointers? All calls, except for Interpreter>>primitiveNewMethod,  
and ObjectMemory>>instantiateContext:sizeInBytes:
allocate bytes, those two allocate object. However  
instantiateContext:sizeInBytes: did not do a fill before so it should  
be ok based on historical evidence.

b) Will objects with an identity hash of zero  leak into old space.  
I've attempted to find all occurrences. The expected ones
are at tenure time in the incremental GC, the tenure when doing a full  
GC. Keep in mind the rule is that Old space may already contain  
identity hash values of zero, and image segments we load might contain  
hash values of zero. Also segments we create should of course have  
non-zero hash values for all objects we store into that segment.

Other more exotic ones can be at
ObjectMemory>>restoreHeadersAfterBecoming: with:
ObjectMemory>>restoreHeadersAfterForwardBecome
{For these I don't believe I need to calculate the identity hash at  
this point, but I'm being paranoid, however someone can
confirm this decision and perhaps the code can be removed from these  
two methods)

Then just to complicate things we can expect issues when we store or  
load an image segment.  IE load/save a project.
To avoid issues here what I have done is in
Interpreter>>primitiveLoadImageSegment
Interpreter>>primitiveStoreImageSegment

I invoke a incremental GC and force the tenure of all the objects to  
oldspace which triggers doing an identity hash
creation on all survivors. Then the primitiveStoreImageSegment which  
copies everything to the supplied chunk of memory  will of course find  
only Old Space objects with non-zero identity hash values.  The  
primitiveLoadImageSegment will end up remapping
the segment that contains the loaded objects into a set of real objects  
and as far as I know it doesn't invoke an allocation, also it
will of course find the segment in oldspace because of the earlier  
forced tenure event, and if it brings into objects with a hash value of  
zero they won't be converted.

Confirmation that I've managed to make this bit of code work correctly  
because I'm not an expert on how the image segment loading/unloading  
works would be welcome. Missing in my test suite is  a before after  
check on hash identity zero counts... Oh well tomorrow...

Note when we migrate to v4.x and have an image format change we can  
switch to all identity hash values
being non-zero when used, and remove the logic to hash when moving  
objects out of youngSpace which saves a bit
of CPU time and avoids complexity, by falling back on the rule of  
identity hash = 0 is a marker to invoke the hash.


PS some rewriting of New: might occur later this month, because I  
noticed we check for space in youngSpace for the new,
force a igc/fullgc etc if not enough, then if ok we invoke the same  
space checks & logic before allocating the object. Seem we
could do the check once, by changing the failure mode in the allocation  
logic to decide if the failure is a VM core dump, or a
primitive fail.
--
======================================================================== 
===
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: AllocateNoFillNoHash-JMM.3.cs.gz
Type: application/x-gzip
Size: 13948 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030715/67cdf49d/AllocateNoFillNoHash-JMM.3.cs.bin