[Vm-dev] Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

[Mariano Martinez Peck]

On Tue, Sep 28, 2010 at 11:11 AM, Henrik Johansen <
henrik.s.johansen at veloxit.no> wrote:

>
>
> On Sep 28, 2010, at 9:36 27AM, Mariano Martinez Peck wrote:
>
>
>
> On Tue, Sep 28, 2010 at 6:46 AM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>> 2010/9/27 Eliot Miranda <eliot.miranda at gmail.com>:
>> >
>> >
>> >
>> > On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>> >>>
>> >>>
>> >>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <
>> henrik.s.johansen at veloxit.no> wrote:
>> >>>>
>> >>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:
>> >>>>
>> >>>> > Some notes:
>> >>>> >
>> >>>> > - What should be answered for small ints? 1 sizeInMemory -->8.
>> That's wrong. Shouldn't this answer 0?
>> >>>>
>> >>>> Philosophical question really, imo both 4 (Again, in 32bit images at
>> least) and 0 would be "correct" answers in their own ways. 8 is definitely
>> wrong though :)
>> >>>> The method comment should probably highlight which definition is
>> used.
>> >>>>
>> >>
>> >>
>> >> So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?
>> >
>> > 0 bytes, obviously.  The only space occupied by a SmallInteger is the
>> space of the slot containing it.  There is no SmallInteger object beyond the
>> slot.
>> >
>>
>> Or from another POV, it's 4, the size of the slot. But we don't count
>> the size of the slots, they are already counted in the containing
>> object, that's why it should answer 0.
>>
>
>
> Thanks for the answers. I finally let this:
>
> sizeInMemory
>     "Answer the number of bytes consumed by this instance including object
> header."
>     | isCompact headerBytes contentBytes |
>
>     "SmallInteger occupy 0 bytes since the only space occupied by a
> SmallInteger is the space of the slot containing it.  There is no
> SmallInteger object beyond the slot. From another POV, it could be 4, the
> size of the slot. But we don't count the size of the slots, they are already
> counted in the containing object, that's why it should answer 0."
>     (self isMemberOf: SmallInteger) ifTrue: [^0].
>
>      contentBytes := self class instSize * Smalltalk wordSize. "inst vars"
>
>      self class isVariable ifTrue:[ |bytesPerElement|
>             bytesPerElement := self class isBytes ifTrue: [1] ifFalse: [4].
>             contentBytes := contentBytes + (self basicSize *
> bytesPerElement)].
>
>      isCompact := self class indexIfCompact > 0.
>       headerBytes :=
>                     contentBytes > 255
>                         ifTrue: [ 3 * Smalltalk wordSize ]
>                         ifFalse: [isCompact ifTrue: [Smalltalk wordSize]
> ifFalse: [2 * Smalltalk wordSize]].
>             ^ headerBytes + contentBytes
>
>
> Now I wonder...maybe instead of doing this it is easier to have a primitive
> that just calls #internalByteSize: ?
> The problem of course is that it needs changes in the vm...
>
> cheers
>
> Mariano
>
>
> isMemberOf: is so quaint...
>
> Why not
> SmallInteger>>sizeInMemory
>     "SmallInteger occupy 0 bytes since the only space occupied by a
> SmallInteger is the space of the slot containing it.
> There is no SmallInteger object beyond the slot.
> From another POV, it could be 4, the size of the slot. But we don't count
> the size of the slots, they are already counted in the containing object,
> that's why it should answer 0."
> ^0
>
> and remove that part from the Object implementation.
>
>
Uffff thanks Henrik for enlight me and teach me. Shame on me. I think that
too much paper writting, ppt and admin tasks are killing me :(
But don't worry, now I will come to code again! Hope to recover... :)



> Cheers,
> Henry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100928/475f9750/attachment.htm