[Vm-dev] Simple question about objects, headers and sizes

Mariano Martinez Peck marianopeck at gmail.com
Mon Jun 6 07:21:41 UTC 2011


On Mon, Jun 6, 2011 at 6:09 AM, Javier Pimás <elpochodelagente at gmail.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110606/582d9d47/attachment.htm


More information about the Vm-dev mailing list