On 19.08.2009, at 06:38, Michael van der Gulik wrote:

>
> If you look at the implementation of ProtoObject>>identityHash, it  
> is primitive 75. If you look at the implementation of Object>>asOop,  
> it is also primitive 75. So, coincidentally, yes, it is an OOP  
> (object pointer).

Wrong. You can neither access nor "dereference" OOPs from inside the  
image.

The comment in Object>>asOop does not reflect reality anymore.

The original (Blue Book) Smalltalk-80 VM used an object table. OOPs  
were indices into the object table. They were even, because each  
object table entry stored a 16 bit pointer to the actual object. Odd  
OOPs represented SmallIntegers in theri upper 15 bits. So the lowest  
bit indicated whether an OOP was an object table index or an  
"immediate" integer value. OOPs never changed over the lifetime of an  
object, garbage collection (which moves objects around in memory) only  
had to change the object table entry.

In the Squeak VM, there is no object table. It uses a "direct pointer"  
model. Each OOP is 32 bits (*). Odd OOPs still represent SmallIntegers  
in their upper 31 bits, but even OOPs are a direct pointer to an  
object. This means that when garbage is collected and an object moves,  
its OOP changes. This is not observable from the image.

Now, in Smalltalk-80, #identityHash was calculated as the OOP divided  
by 2 (they where even, remember? SmallIntegers are their own  
identityHash), because the OOP was constant for each object, so a good  
base for knowing identity. In Squeak, an equivalent was needed. There  
are 12 bits in the Squeak object header that get assigned when the  
object is created, and are moved around with the object when  
compacting memory. Primitive 75 returns these hash bits now, despite  
its name:

primitiveAsOop
	| thisReceiver |
	thisReceiver := self stackTop.
	self success: (self isIntegerObject: thisReceiver) not.
	successFlag
		ifTrue: [self pop:1 thenPushInteger: (self hashBitsOf: thisReceiver)]

hashBitsOf: oop
	^ ((self baseHeader: oop) >> 17) bitAnd: 16rFFF

> The intention however was just to print out a number that is unique  
> for each different instance so that you can see whether two  
> variables are pointing to the same morph. This is useful for  
> debugging.

Indeed. IMHO, all uses of #asOOP should be replaced by #identityHash  
(outside of the VMMaker package anyway), and the comment in asOOP  
updated (or remove it altogether).

- Bert -

(*) Even in a VM compiled on a 64 bit host OOPs are 32 bits. Only in  
"64 bit images" OOPs are extended to 64 bits, but they are not in use  
yet. And we might rather like to re-introduce an object table anyway,  
which even with 32 bit OOPs would give us 2 billion objects ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090819/b0453259/attachment.htm