ImageSegment, objects header and addresses

 
Hi guys. There is something I still don't understand about ImageSegment hahaha. But each time there is less :)

There is a place in ImageSegment >> copyObj: oop toSegment: segmentWordArray addr: lastSeg stopAt: stopAddr saveOopAt: oopPtr headerAt: hdrPtr
where it does this:

    self forward: oop to: (lastSeg+BytesPerWord + extraSize - segmentWordArray)
        savingOopAt: oopPtr andHeaderAt: hdrPtr.


Basically, it forwards oop to another address which is actually the offset inside the segment. And it backups the original oop and the hader, as you can see here:

Interpreter >> forward: oop to: newOop savingOopAt: oopPtr andHeaderAt: hdrPtr

    "Make a new entry in the table of saved oops."
    self longAt: oopPtr put: oop.                    "Save the oop"
    self longAt: hdrPtr put: (self longAt: oop).    "Save the old header word"

    "Put a forwarding pointer in the old object, flagged with forbidden header type"
    self longAt: oop put: newOop + HeaderTypeFree.


Now....the line I don't understand is this:

    self longAt: oop put: newOop + HeaderTypeFree.

Because 'self longAt: oop' 
will answer the object header of oop. And there, it stores a number (the offset). Is this possible?

In addition, it not only stores the offset, by it plus the flag HeaderTypeFree.

I really don't understand how you can plus an offset and the flag. What is the result? how should I interpret that?

Thanks for any hint you can give me.

Mariano

 
On Tuesday 27 Jul 2010 8:02:29 pm Mariano Martinez Peck wrote: A oop is an offset. Since every oop is aligned to a 4-word boundary the least
significant two bits are always zero. So these two bits are re-used for a
typecode (0..3).

HTH .. Subbu

 

 
On Thu, Jul 29, 2010 at 10:27:03AM +0200, Mariano Martinez Peck wrote:
See first the class comment of ObjectMemory for the overall description
of how this works. In that comment (and throughout much of the code for
ObjectMemory and Interpreter) the term "pointer" is the same as "oop".
An object memory pointer is a byte-addressable offset into the object
memory, and the object memory is just a big array of 32-bit words (or
64-bit words in the case of the 64-bit object memory format).

The use of a byte-addressable object memory pointer (rather than a
32-bit or 64-bit word addressable pointer as one might have expected)
has the nice property that only every fourth (or eighth) value actually
points to a valid address in the object memory. That means that any time
you see a pointer that does not point to a valid word, you know that
it is not really a pointer after all.

This is what permits the trick of saying that if the oop has an odd
value (low order bit is set), then treat it as a short integer and
use the remaining 31 bits of the "oop" as the value of that integer.
Computationally, it's just a matter of check the low order bit, and
if it is set, shift right one to obtain the integer value.

This is also the reason that for any valid object memory pointer
(aka oop), the two low-order bits of the pointer must be zero.
Anything else points to something other than a 4 (or 8) byte boundary
in the object memory, and therefore is not pointing to a valid location
in the object memory.

Dave

 
On Thursday 29 Jul 2010 1:57:03 pm Mariano Martinez Peck wrote:
> On Tue, Jul 27, 2010 at 6:10 PM, K. K. Subramaniam > > A oop is an offset.
Since every oop is aligned to a 4-word boundary
>
> ok.....each oop is 4-word -> 32 bits, 4 bytes. I am right?  One is used to
> mark SmalltalkIntegers. But here, that doesn't matter.
Yes, 4-word should actually read 4-byte word. Mea culpa :-(.

> > the least
> > significant two bits are always zero.
>
> why? I don't understand this. Why the last two bits are always zero?
> because ImageSegment assumes that the size of the segment will be much
> smaller?
No. Because an oop is a 4-byte aligned pointer. Its last two bits will always
be zero. The choice and position of bits in an oop and special bits in an
object header gives us a quick way to compute byte offsets into object memory.

HTH .. Subbu