Multiple disjoint object memory in Smalltalk

John M McIntosh johnmci at smalltalkconsulting.com
Tue May 29 05:39:25 UTC 2001


>  > I note that on some versions of mmap you can speicify a starting
>>  address. Therefore if it works you could avoid having to swizzle the
>>  pointers when you access the image since they would never change.
>>  Otherwise you are back to updating all the object slots at load time.
>
>The method ObjectMemory>>adjustAllOopsBy in my image was last updated by
>you, I believe (JMM 11/18/2000 17:50).

Ok, I've got my initials on it by accident. The change made was
"di 11/18/2000 - return number of objects found" which I happened to 
do for Dan at his request to solve the multiple GC events because the 
forwarding table was full. The forwarding table now is sized by the 
number of objects in the image, so that number comes from somewhere, 
and Dan added code to snatch it from this method.

Now I can't speak for the comment...
And I wonder if it's fixed?
See self longAt: oop put: (header bitAnd: AllButRootBit). clears that 
Root Bit everywhere. But I'd think ObjectMemory>>clearRootsTable 
should do that which is called from fullGC which is called from 
ObjectMemory>>primitiveSnapshot.

So anyone know if this is still a bug? Or is it dead.

Still need to count those objects tho...

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





More information about the Squeak-dev mailing list