Simple question about objects, headers and sizes

 
Hi, I'm investigating the format of objects in memory. After some time I got this conclusions/questions I'd like to know more about:

- Oops must be at least 16 bits aligned, because of SmallIntegers tagging, is that right?

- Raw object sizes are 32 bits aligned, because of size field in header which is in 32 bits words. So that for byte indexed instances there may be at most 3 wasted bytes (format field in that case tell the amount not used of the last 4 bytes).

Is that the way that the VM assures the alignment of the oops?

- And the last one and the most puzzling for me: how does objectAfter: anOop work? I mean, for what I see, it returns the addition of anOop and the size of the object pointed by anOop, but how can it be sure that that is the base header and not the size or class field of the extended header?

 

On Mon, Jun 6, 2011 at 6:09 AM, Javier Pimás <[hidden email]> wrote:

 
Hi, I'm investigating the format of objects in memory. After some time I got this conclusions/questions I'd like to know more about:

- Oops must be at least 16 bits aligned, because of SmallIntegers tagging, is that right?

Aren't they 31 bits? There is only one tag bit.
SmallInteger maxVal = 1073741823
(2 raisedTo: 30) - 1 1073741823
30 because there is another bit for the sign I think.

 

- Raw object sizes are 32 bits aligned, because of size field in header which is in 32 bits words. So that for byte indexed instances there may be at most 3 wasted bytes (format field in that case tell the amount not used of the last 4 bytes).

Yes, for example 'a', 'bb', 'ccc' and 'dddd' they all occupy 4 bytes in the VM (we discuss about that recently in the thread of Fuel I think). The VM knows how much are really used by accessing the "size" value in the object header.

 

Is that the way that the VM assures the alignment of the oops?

- And the last one and the most puzzling for me: how does objectAfter: anOop work? I mean, for what I see, it returns the addition of anOop and the size of the object pointed by anOop, but how can it be sure that that is the base header and not the size or class field of the extended header?

I am not sure if I understood. #objectAfter:  uses #sizeBitsOf:

sizeBitsOf: oop
    "Answer the number of bytes in the given object, including its base header, rounded up to an integral number of words."
    "Note: byte indexable objects need to have low bits subtracted from this size."

    | header |
    header := self baseHeader: oop.
    (header bitAnd: TypeMask) = HeaderTypeSizeAndClass
        ifTrue: [ ^ (self sizeHeader: oop) bitAnd: LongSizeMask ]
        ifFalse: [ ^ header bitAnd: SizeMask ].

 

Cheers


--
Mariano
http://marianopeck.wordpress.com

On 06.06.2011, at 08:46, Javier Pimás wrote:

>  A better question would be, what is the bit format of the extra header?

See the class comment for ObjectMemory:

"If a class is in the compact class table, then this is the only header information needed.  If it is not, then it will have another header word at offset -4 bytes with its class in the high 30 bits, and the header type repeated in its low 2 bits.  It the objects size is greater than 255 bytes, then it will have yet another header word at offset -8 bytes with its full word size in the high 30 bits and its header type repeated in the low two bits."


- Bert -