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

[Mariano Martinez Peck]

Ok...I have just commited. If you want to review:

http://code.google.com/p/pharo/issues/detail?id=3032

cheers

Mariano

On Tue, Sep 28, 2010 at 1:45 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> 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/20101001/45f5f59c/attachment.htm