[squeak-dev] Newbie Question (about OOPs, maybe) (sorry)

Hi Bert,
My answers inline below.

On 2009.08.22 17:26, Bert Freudenberg wrote:

On 22.08.2009, at 12:39, Trygve Reenskaug wrote:

Object>>asOop
    "Primitive. Answer a SmallInteger whose value is half of the receiver's 
    object pointer (interpreting object pointers as 16-bit signed quantities)..."

ProtoObject>>identityHash
    "Answer a SmallInteger whose value is related to the receiver's identity..."
This is pretty vague, but the term 'Hash' indicates that many objects can share the same value. So it is clearly cannot be used as the objectID.

The Morph>>printOn: implementation is less than ideal because it should apply to all objects, not only Morphs. Also, it should use 'asOop' rather than 'identityHash' to let us hope for uniqueness.

You might have overlooked that both these methods are identical.

I do know it and interpret this to mean that the current Squeak VM happens to have unique hash values. There is no guarantee that another version of the VM will have this invariant.

In short:

• Smalltalk claims to be object oriented and I regard it as a serious flaw that the object ID is not explicitly visible.

What if there simply *is* no object ID?

In Smalltalk, a value is a pointer to an object. Bluebook p. 564: "Each object is associated with a unique identifier called its object pointer. ..."
Smalltalk MUST have such unique identifiers to work. I see this pointer as the object's ID. I have seen from the discussion in this track that the VM can actually change this "unique" pointer.

IMO, a Smalltalk user/programmer should not need to understand the VM. Alan Kay' once said something like "everything in computing is about illusions". One such illusion is that the unique object identifier is immutable. When debugging, I also find it useful that it shall be possible to make it visible, but this is not essential for Smalltalk to work.

• We probably need a 64-bit VM to represent it properly, e.g., using the standardized definition of OID, but a value that is guaranteed to be unique within the current set of objects would be acceptable..

What is the "standardized definition of OID"?

See the Wikipedia article http://en.wikipedia.org/wiki/Object_identifier

• I regard it as a bug that Object>>printOn: does not present some kind of object ID.

Has never bothered me.

I tend to think and work in terms of objects and object structures. Then I need it.

- Bert -

--Trygve

On 23.08.2009, at 11:42, Trygve Reenskaug wrote:

Hashes are non-unique by definition. Indeed, in the Squeak VM they are  
just 12 bits. In the trunk version, asOop now looks like this:

asOop
        ^self identityHash

>>> In short:
>>> • Smalltalk claims to be object oriented and I regard it as a  
>>> serious flaw that the object ID is not explicitly visible.
>>
>> What if there simply *is* no object ID?
> In Smalltalk, a value is a pointer to an object. Bluebook p. 564:  
> "Each object is associated with a unique identifier called its  
> object pointer. ..."

... digs out Blue Book ...

Yes. This is the VM implementation chapter. IMHO it does not mean an  
OOP has to be accessible from the image as an integer.

> Smalltalk MUST have such unique identifiers to work. I see this  
> pointer as the object's ID. I have seen from the discussion in this  
> track that the VM can actually change this "unique" pointer.

The VM can do anything as long as you can't tell from the image. And  
you can't. OOPs cannot be accessed directly.

> IMO, a Smalltalk user/programmer should not need to understand the  
> VM. Alan Kay' once said something like "everything in computing is  
> about illusions". One such illusion is that the unique object  
> identifier is immutable. When debugging, I also find it useful that  
> it shall be possible to make it visible, but this is not essential  
> for Smalltalk to work.

Object references are immutable. They just do not have an integer  
representation. "Identifier" comes from "identity", and you can test  
identity using "==". This is fact compares OOPs.

>>> • We probably need a 64-bit VM to represent it properly, e.g.,  
>>> using the standardized definition of OID, but a value that is  
>>> guaranteed to be unique within the current set of objects would be  
>>> acceptable..
>>
>> What is the "standardized definition of OID"?
> See the Wikipedia article http://en.wikipedia.org/wiki/Object_identifier

I found this page before actually. Nowhere does it say that we need a  
unique integer for every object in a Smalltalk image. This document  
talks about a "hierarchically-assigned namespace", so I did not think  
it was relevant to this discussion.

>>> • I regard it as a bug that Object>>printOn: does not present  
>>> some kind of object ID.
>>
>> Has never bothered me.
> I tend to think and work in terms of objects and object structures.  
> Then I need it.


I do, too. I think in terms of objects and object structures - *not*  
of integers to identify them.

- Bert -

On Sun, Aug 23, 2009 at 04:36:24PM +0200, Bert Freudenberg wrote:
To illustrate the current behavior in Squeak, I used a plugin that
displays OOP values, addresses, etc. Thus:

  (1 to: 100) do: [:e | Array with: e]. "make some garbage"
  aString := 'Hello there'. "allocate an object"
  aString asOop. => 1422 "identity hash for the object"
  OopPlugin oopPrintStringHex: aString. '16r0FF3BE64' "current OOP value"
  OopPlugin machineAddressPrintStringHex: aString. '16r00002B66BBE8AE54' "C pointer to object header"
  Smalltalk garbageCollect. "cause objects to move around in the object memory"
  aString asOop. => 1422 "identity hash remains the same"
  OopPlugin oopPrintStringHex: aString. => '16r0FF36954' "OOP value has changed"
  OopPlugin machineAddressPrintStringHex: aString. => '16r00002B66BBE85944' "object has moved"

The OOP is a unique identifier for the object at a particular instant in
time, but the VM is free to change it at any time without telling you.

Dave

On 23-Aug-09, at 8:52 AM, David T. Lewis wrote:

> The OOP is a unique identifier for the object at a particular  
> instant in
> time, but the VM is free to change it at any time without telling you.
>
> Dave

David doesn't mention this but when you are building primitives there  
is a call that lets you
push the oops onto a stack. This special stack then is managed by the  
garbage collector so
when it moves the oops the oops on the stack are then noted and then  
the magic value (aka memory addresses) corrected.

Later you pop the values off and they might be different. In general  
it's

oopsMemoryAddress = "find oops"
push oops onto remember stack
newoops = "allocate oops of class type:"  "which might cause a GC move  
event"
oopsMemoryAddress = pop oops off remermber stack
^oopsMemoryAddress

The issue for people starting out writing primitives is forgetting to  
do this pattern.

If you don't do this it might work ok, because there is the  
possibility that allocating the newoops won't move things,
but on some call it will, then you die because oopsMemoryAddress is  
now pointing somewhere random in oops space.

Years back there was talk about preventing a GC during the newoops but  
we've never moved forward on that.

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================