[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