Hi list,
I need to estimate the size of a data structure in memory and I realized I don't know how much does the header of an object weight or how much memory is used for every i.v. (32bits?) Is this information available in the documentation? In particular i would need to know: - What is the weight of an object without any i.v. (e.g. Object new). - What is the size of each i.v. pointer. Any hints are most welcome. -- Thanks in advance, Andrés _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Andres,
When you install VW, you can install the VM source. The information you want is actually in the various header files for the VM, I think specifically in “oop.h”. For a 32-bit VM, the size of an object pointer is 32-bits. For a 64-bit VM, it’s 64 bits. SmallIntegers fit within the same memory unit as the object pointer, either 32 or 64 bits, but is smaller to compensate for the tag bits that identity the kind of oop. For 32-bit VMs, this is 2 bits, so a SmallInteger is 30 bits (29+sign). On 64-bit VMs, this is 3 bits, so a SmallInteger is 61 bits (60+sign). Further, a new type is added, SmallDouble, which has the precision (mantissa) of a Double but the exponent range of a Float.
The object header overhead is different between 32-bit and 64-bit VMs. I don’t recall the numbers accurately, only that 64-bit VMs are larger (but not by much), so I won’t put guesses here. I also thought that memory consumption varies with where the object is allocated – that is, in which space.
Cheers!
Tom Hawker -------------------------- Senior Framework Developer -------------------------- Home +1 (408) 274-4128 Office +1 (408) 576-6591 Mobile +1 (408) 835-3643
-----Original Message-----
Hi list, I need to estimate the size of a data structure in memory and I realized I don't know how much does the header of an object weight or how much memory is used for every i.v. (32bits?) Is this information available in the documentation? In particular i would need to know: - What is the weight of an object without any i.v. (e.g. Object new). - What is the size of each i.v. pointer.
Any hints are most welcome.
-- Thanks in advance, Andrés _______________________________________________ vwnc mailing list vwnc@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Fortier-2
On Tue, Oct 20, 2009 at 8:59 AM, andres <[hidden email]> wrote: Hi list, There are methods in ObjectMemory which answer these questions. See ObjectMemory protocol utilities.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by thomas.hawker
Thanks for the info Thomas! I was hoping to avoid going so low-level :).
I'll see if, as Eliot suggested, ObjectMemory has the answers to my questions. Thanks again, Andrés [hidden email] escribió: > Andres, > > > > When you install VW, you can install the VM source. The information you want is actually in the various header files for the VM, I think specifically in "oop.h". For a 32-bit VM, the size of an object pointer is 32-bits. For a 64-bit VM, it's 64 bits. SmallIntegers fit within the same memory unit as the object pointer, either 32 or 64 bits, but is smaller to compensate for the tag bits that identity the kind of oop. For 32-bit VMs, this is 2 bits, so a SmallInteger is 30 bits (29+sign). On 64-bit VMs, this is 3 bits, so a SmallInteger is 61 bits (60+sign). Further, a new type is added, SmallDouble, which has the precision (mantissa) of a Double but the exponent range of a Float. > > > > The object header overhead is different between 32-bit and 64-bit VMs. I don't recall the numbers accurately, only that 64-bit VMs are larger (but not by much), so I won't put guesses here. I also thought that memory consumption varies with where the object is allocated - that is, in which space. > > > > Cheers! > > > > Tom Hawker > > -------------------------- > > Senior Framework Developer > > -------------------------- > > Home +1 (408) 274-4128 > > Office +1 (408) 576-6591 > > Mobile +1 (408) 835-3643 > > > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of andres > Sent: Tuesday, October 20, 2009 9:00 AM > To: VWNC List > Subject: [vwnc] Size of an object > > > > Hi list, > > I need to estimate the size of a data structure in memory and > > I realized I don't know how much does the header of an object weight or > > how much memory is used for every i.v. (32bits?) Is this information > > available in the documentation? In particular i would need to know: > > - What is the weight of an object without any i.v. (e.g. Object new). > > - What is the size of each i.v. pointer. > > > > Any hints are most welcome. > > > > -- > > Thanks in advance, > > Andrés > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > IMPORTANT NOTICE > Email from OOCL is confidential and may be legally privileged. If it is not > intended for you, please delete it immediately unread. The internet > cannot guarantee that this communication is free of viruses, interception > or interference and anyone who communicates with us by email is taken > to accept the risks in doing so. Without limitation, OOCL and its affiliates > accept no liability whatsoever and howsoever arising in connection with > the use of this email. Under no circumstances shall this email constitute > a binding agreement to carry or for provision of carriage services by OOCL, > which is subject to the availability of carrier's equipment and vessels and > the terms and conditions of OOCL's standard bill of lading which is also > available at http://www.oocl.com. > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Eliot Miranda-2
Thanks Eliot, I'll check it right away.
Cheers, Andrés Eliot Miranda escribió: > On Tue, Oct 20, 2009 at 8:59 AM, andres <[hidden email]>wrote: > >> Hi list, >> I need to estimate the size of a data structure in memory and >> I realized I don't know how much does the header of an object weight or >> how much memory is used for every i.v. (32bits?) Is this information >> available in the documentation? In particular i would need to know: >> - What is the weight of an object without any i.v. (e.g. Object new). >> - What is the size of each i.v. pointer. >> >> Any hints are most welcome. >> > > There are methods in ObjectMemory which answer these questions. See > ObjectMemory protocol utilities. > > > >> -- >> Thanks in advance, >> Andrés >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Eliot Miranda-2
Thanks Eliot, it seems like #bytesPerOTE, #bytesPerOOP and
#numOopsNumBytesIn: aCollection is what I was looking for. Cheers, Andrés Eliot Miranda escribió: > On Tue, Oct 20, 2009 at 8:59 AM, andres <[hidden email]>wrote: > >> Hi list, >> I need to estimate the size of a data structure in memory and >> I realized I don't know how much does the header of an object weight or >> how much memory is used for every i.v. (32bits?) Is this information >> available in the documentation? In particular i would need to know: >> - What is the weight of an object without any i.v. (e.g. Object new). >> - What is the size of each i.v. pointer. >> >> Any hints are most welcome. >> > > There are methods in ObjectMemory which answer these questions. See > ObjectMemory protocol utilities. > > > >> -- >> Thanks in advance, >> Andrés >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On Tue, Oct 20, 2009 at 1:40 PM, andres <[hidden email]> wrote: Thanks Eliot, it seems like #bytesPerOTE, #bytesPerOOP and
In the 32-bit system the size is 11 bits and is a byte size. If the byte size is >= (2^11)-32 it has an overflow word. i.e. >= 2016 bytes or >= 504 inst vars. In the 64-bit system the size is 8 bytes and is a 64-bit word size. If the word size is >= (2^8)-4 it has an overflow word. i.e. >= 2016 bytes or >= 252 inst vars. The reserved size values are used to tag objects in fixed space. These always have an extra size word (and a further 5 (count 'em and weep)) words of overhead, which is bytesPerFTE.
This information should be included in an ObjectMemory (the width of the small size field, whether the small size field is words or bytes, and the number of reserved values in the size field). But I hadn't got around to it when I left Cincom. You could hard-code the above values if you want accurate size estimates.
HTH Eliot
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thanks for the information Eliot. So I guess
ObjectMemory current numOopsNumBytesIn: (Array with: obj). is not enough to know the size of "obj". By the way, could you explain to me the code for computing the size of a byte object? (object basicSize + (bytesInOOP - 1) bitAnd: bytesInOOP negated) Thanks in advance, Andrés Eliot Miranda escribió: > On Tue, Oct 20, 2009 at 1:40 PM, andres <[hidden email]>wrote: > >> Thanks Eliot, it seems like #bytesPerOTE, #bytesPerOOP and >> #numOopsNumBytesIn: aCollection is what I was looking for. >> >> Cheers, >> Andrés >> > > Beware that these values are an underestimate for large objects and for >> fixed space objects. An object contains a small size field, and if its size >> won't fit in that field another word is allocated in front of the object >> which holds its full size. >> > > In the 32-bit system the size is 11 bits and is a byte size. If the byte > size is >= (2^11)-32 it has an overflow word. i.e. >= 2016 bytes or >= 504 > inst vars. > > In the 64-bit system the size is 8 bytes and is a 64-bit word size. If the > word size is >= (2^8)-4 it has an overflow word. i.e. >= 2016 bytes or >= > 252 inst vars. > > The reserved size values are used to tag objects in fixed space. These > always have an extra size word (and a further 5 (count 'em and weep)) words > of overhead, which is bytesPerFTE. > > This information should be included in an ObjectMemory (the width of the > small size field, whether the small size field is words or bytes, and the > number of reserved values in the size field). But I hadn't got around to it > when I left Cincom. You could hard-code the above values if you want > accurate size estimates. > > HTH > Eliot > > Eliot Miranda escribió: >>> On Tue, Oct 20, 2009 at 8:59 AM, andres <[hidden email] >>> wrote: >>> >>>> Hi list, >>>> I need to estimate the size of a data structure in memory and >>>> I realized I don't know how much does the header of an object weight or >>>> how much memory is used for every i.v. (32bits?) Is this information >>>> available in the documentation? In particular i would need to know: >>>> - What is the weight of an object without any i.v. (e.g. Object new). >>>> - What is the size of each i.v. pointer. >>>> >>>> Any hints are most welcome. >>>> >>> There are methods in ObjectMemory which answer these questions. See >>> ObjectMemory protocol utilities. >>> >>> >>> >>>> -- >>>> Thanks in advance, >>>> Andrés >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On Wed, Oct 21, 2009 at 1:17 PM, andres <[hidden email]> wrote: Thanks for the information Eliot. So I guess simply that byte objects are rounded up to a whole word in size. So in the 32-bit system a 1-byte object takes 16 bytes, 12 bytes for the header plus 4 for the rounded up single byte. In the 64-bit system it would take 24 bytes, 16 bytes for the header plus 8 bytes for the rounded up single byte.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Ok, thanks!
Eliot Miranda escribió: > On Wed, Oct 21, 2009 at 1:17 PM, andres <[hidden email]>wrote: > >> Thanks for the information Eliot. So I guess >> >> ObjectMemory current numOopsNumBytesIn: (Array with: obj). >> >> is not enough to know the size of "obj". >> >> By the way, could you explain to me the code for computing the size of a >> byte object? >> >> (object basicSize + (bytesInOOP - 1) bitAnd: bytesInOOP negated) >> > > simply that byte objects are rounded up to a whole word in size. So in the > 32-bit system a 1-byte object takes 16 bytes, 12 bytes for the header plus 4 > for the rounded up single byte. In the 64-bit system it would take 24 > bytes, 16 bytes for the header plus 8 bytes for the rounded up single byte. > > >> Thanks in advance, >> Andrés >> >> >> >> Eliot Miranda escribió: >> >>> On Tue, Oct 20, 2009 at 1:40 PM, andres <[hidden email] >>>> wrote: >>> Thanks Eliot, it seems like #bytesPerOTE, #bytesPerOOP and >>>> #numOopsNumBytesIn: aCollection is what I was looking for. >>>> >>>> Cheers, >>>> Andrés >>>> >>>> >>> Beware that these values are an underestimate for large objects and for >>> >>>> fixed space objects. An object contains a small size field, and if its >>>> size >>>> won't fit in that field another word is allocated in front of the object >>>> which holds its full size. >>>> >>>> >>> In the 32-bit system the size is 11 bits and is a byte size. If the byte >>> size is >= (2^11)-32 it has an overflow word. i.e. >= 2016 bytes or >= >>> 504 >>> inst vars. >>> >>> In the 64-bit system the size is 8 bytes and is a 64-bit word size. If >>> the >>> word size is >= (2^8)-4 it has an overflow word. i.e. >= 2016 bytes or >= >>> 252 inst vars. >>> >>> The reserved size values are used to tag objects in fixed space. These >>> always have an extra size word (and a further 5 (count 'em and weep)) >>> words >>> of overhead, which is bytesPerFTE. >>> >>> This information should be included in an ObjectMemory (the width of the >>> small size field, whether the small size field is words or bytes, and the >>> number of reserved values in the size field). But I hadn't got around to >>> it >>> when I left Cincom. You could hard-code the above values if you want >>> accurate size estimates. >>> >>> HTH >>> Eliot >>> >>> Eliot Miranda escribió: >>> >>>> On Tue, Oct 20, 2009 at 8:59 AM, andres <[hidden email] >>>>> wrote: >>>>> >>>>> Hi list, >>>>>> I need to estimate the size of a data structure in memory and >>>>>> I realized I don't know how much does the header of an object weight or >>>>>> how much memory is used for every i.v. (32bits?) Is this information >>>>>> available in the documentation? In particular i would need to know: >>>>>> - What is the weight of an object without any i.v. (e.g. Object new). >>>>>> - What is the size of each i.v. pointer. >>>>>> >>>>>> Any hints are most welcome. >>>>>> >>>>>> There are methods in ObjectMemory which answer these questions. See >>>>> ObjectMemory protocol utilities. >>>>> >>>>> >>>>> >>>>> -- >>>>>> Thanks in advance, >>>>>> Andrés >>>>>> _______________________________________________ >>>>>> vwnc mailing list >>>>>> [hidden email] >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> vwnc mailing list >>>>> [hidden email] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>>> > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Eliot Miranda-2
Eliot, (sorry) but I don't think I fully understand. Please, tell me
where I'm wrong (I'm sticking to 32 bits for the sake of clarity): - There are two main situations where the computed size may be wrong: when the object is in the fixed space or when we are handling large objects. Case 1: the object is in the fixed space. According to the documentation is actually the object's body that is in the fixed space. bytesPerFTE is 20 in my case, which is the overhead for having an extra reference for the object's body in the fixed space, right? If this is ok, my question now is: how can I tell if an object is residing in the fixed space? Case 2: the object is too large and thus needs an extra byte size to store its actual size. - If the object is #bytes and basicSize >= 2016 (e.g. 3000) then I should add 1 byte. So its final size would be: bytesInHeader + (self basicSize + (bytesInOOP - 1) bitAnd: bytesInOOP negated) + 1. - If the object is not #bytes and (instSize + basicSize) >= 252 (e.g. 300) then I should add 1 byte. So its final size would be: | bytes | bytes:=bytesInHeader + (self class instSize * bytesInOOP). self class isVariable ifTrue: [bytes:=bytes + (self basicSize * bytesInOOP)]. bytes + 1. Is there anything that I'm missing? Thanks in advance, Andrés Eliot Miranda escribió: > On Tue, Oct 20, 2009 at 1:40 PM, andres <[hidden email]>wrote: > >> Thanks Eliot, it seems like #bytesPerOTE, #bytesPerOOP and >> #numOopsNumBytesIn: aCollection is what I was looking for. >> >> Cheers, >> Andrés >> > > Beware that these values are an underestimate for large objects and for >> fixed space objects. An object contains a small size field, and if its size >> won't fit in that field another word is allocated in front of the object >> which holds its full size. >> > > In the 32-bit system the size is 11 bits and is a byte size. If the byte > size is >= (2^11)-32 it has an overflow word. i.e. >= 2016 bytes or >= 504 > inst vars. > > In the 64-bit system the size is 8 bytes and is a 64-bit word size. If the > word size is >= (2^8)-4 it has an overflow word. i.e. >= 2016 bytes or >= > 252 inst vars. > > The reserved size values are used to tag objects in fixed space. These > always have an extra size word (and a further 5 (count 'em and weep)) words > of overhead, which is bytesPerFTE. > > This information should be included in an ObjectMemory (the width of the > small size field, whether the small size field is words or bytes, and the > number of reserved values in the size field). But I hadn't got around to it > when I left Cincom. You could hard-code the above values if you want > accurate size estimates. > > HTH > Eliot > > Eliot Miranda escribió: >>> On Tue, Oct 20, 2009 at 8:59 AM, andres <[hidden email] >>> wrote: >>> >>>> Hi list, >>>> I need to estimate the size of a data structure in memory and >>>> I realized I don't know how much does the header of an object weight or >>>> how much memory is used for every i.v. (32bits?) Is this information >>>> available in the documentation? In particular i would need to know: >>>> - What is the weight of an object without any i.v. (e.g. Object new). >>>> - What is the size of each i.v. pointer. >>>> >>>> Any hints are most welcome. >>>> >>> There are methods in ObjectMemory which answer these questions. See >>> ObjectMemory protocol utilities. >>> >>> >>> >>>> -- >>>> Thanks in advance, >>>> Andrés >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Andrés,
I thought Eliot said one oop, not one byte. Allocation is always done in “oop”-sized units, so the size field would be 4-bytes on a 32-bit VM. If you overflow to that extra word, one byte isn’t enough to hold the size.
Cheers!
Tom Hawker -------------------------- Senior Framework Developer -------------------------- Home +1 (408) 274-4128 Office +1 (408) 576-6591 Mobile +1 (408) 835-3643
-----Original Message-----
Eliot, (sorry) but I don't think I fully understand. Please, tell me where I'm wrong (I'm sticking to 32 bits for the sake of clarity):
- There are two main situations where the computed size may be wrong: when the object is in the fixed space or when we are handling large objects.
Case 1: the object is in the fixed space. According to the documentation is actually the object's body that is in the fixed space. bytesPerFTE is 20 in my case, which is the overhead for having an extra reference for the object's body in the fixed space, right? If this is ok, my question now is: how can I tell if an object is residing in the fixed space?
Case 2: the object is too large and thus needs an extra byte size to store its actual size.
- If the object is #bytes and basicSize >= 2016 (e.g. 3000) then I should add 1 byte. So its final size would be:
bytesInHeader + (self basicSize + (bytesInOOP - 1) bitAnd: bytesInOOP negated) + 1.
- If the object is not #bytes and (instSize + basicSize) >= 252 (e.g. 300) then I should add 1 byte. So its final size would be:
| bytes | bytes:=bytesInHeader + (self class instSize * bytesInOOP). self class isVariable ifTrue: [bytes:=bytes + (self basicSize * bytesInOOP)]. bytes + 1.
Is there anything that I'm missing?
Thanks in advance, Andrés
Eliot Miranda escribió: > On Tue, Oct 20, 2009 at 1:40 PM, andres <[hidden email]>wrote: > >> Thanks Eliot, it seems like #bytesPerOTE, #bytesPerOOP and >> #numOopsNumBytesIn: aCollection is what I was looking for. >> >> Cheers, >> Andrés >> >
> Beware that these values are an underestimate for large objects and for >> fixed space objects. An object contains a small size field, and if its size >> won't fit in that field another word is allocated in front of the object >> which holds its full size. >> > > In the 32-bit system the size is 11 bits and is a byte size. If the byte > size is >= (2^11)-32 it has an overflow word. i.e. >= 2016 bytes or >= 504 > inst vars. > > In the 64-bit system the size is 8 bytes and is a 64-bit word size. If the > word size is >= (2^8)-4 it has an overflow word. i.e. >= 2016 bytes or >= > 252 inst vars. > > The reserved size values are used to tag objects in fixed space. These > always have an extra size word (and a further 5 (count 'em and weep)) words > of overhead, which is bytesPerFTE. > > This information should be included in an ObjectMemory (the width of the > small size field, whether the small size field is words or bytes, and the > number of reserved values in the size field). But I hadn't got around to it > when I left Cincom. You could hard-code the above values if you want > accurate size estimates. > > HTH > Eliot > > Eliot Miranda escribió: >>> On Tue, Oct 20, 2009 at 8:59 AM, andres <[hidden email] >>> wrote: >>> >>>> Hi list, >>>> I need to estimate the size of a data structure in memory and >>>> I realized I don't know how much does the header of an object weight or >>>> how much memory is used for every i.v. (32bits?) Is this information >>>> available in the documentation? In particular i would need to know: >>>> - What is the weight of an object without any i.v. (e.g. Object new). >>>> - What is the size of each i.v. pointer. >>>> >>>> Any hints are most welcome. >>>> >>> There are methods in ObjectMemory which answer these questions. See >>> ObjectMemory protocol utilities. >>> >>> >>> >>>> -- >>>> Thanks in advance, >>>> Andrés >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ >> vwnc mailing list >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ vwnc mailing list http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thanks for the correction Tom!
Cheers, Andrés [hidden email] escribió: > Andrés, > > > > I thought Eliot said one oop, not one byte. Allocation is always done in "oop"-sized units, so the size field would be 4-bytes on a 32-bit VM. If you overflow to that extra word, one byte isn't enough to hold the size. > > > > Cheers! > > > > Tom Hawker > > -------------------------- > > Senior Framework Developer > > -------------------------- > > Home +1 (408) 274-4128 > > Office +1 (408) 576-6591 > > Mobile +1 (408) 835-3643 > > > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of andres > Sent: Thursday, October 22, 2009 1:59 PM > To: vwnc NC > Cc: John Sarkela > Subject: Re: [vwnc] Size of an object > > > > Eliot, (sorry) but I don't think I fully understand. Please, tell me > > where I'm wrong (I'm sticking to 32 bits for the sake of clarity): > > > > - There are two main situations where the computed size may be wrong: > > when the object is in the fixed space or when we are handling large objects. > > > > Case 1: the object is in the fixed space. According to the documentation > > is actually the object's body that is in the fixed space. bytesPerFTE is > > 20 in my case, which is the overhead for having an extra reference for > > the object's body in the fixed space, right? > > If this is ok, my question now is: how can I tell if an object is > > residing in the fixed space? > > > > Case 2: the object is too large and thus needs an extra byte size to > > store its actual size. > > > > - If the object is #bytes and basicSize >= 2016 (e.g. 3000) then I > > should add 1 byte. So its final size would be: > > > > bytesInHeader + (self basicSize + (bytesInOOP - 1) bitAnd: bytesInOOP > > negated) + 1. > > > > - If the object is not #bytes and (instSize + basicSize) >= 252 (e.g. > > 300) then I should add 1 byte. So its final size would be: > > > > | bytes | > > bytes:=bytesInHeader + (self class instSize * bytesInOOP). > > self class isVariable ifTrue: [bytes:=bytes + (self basicSize * > > bytesInOOP)]. > > bytes + 1. > > > > Is there anything that I'm missing? > > > > Thanks in advance, > > Andrés > > > > Eliot Miranda escribió: > >> On Tue, Oct 20, 2009 at 1:40 PM, andres <[hidden email]>wrote: > > >>> Thanks Eliot, it seems like #bytesPerOTE, #bytesPerOOP and > >>> #numOopsNumBytesIn: aCollection is what I was looking for. > > >>> Cheers, > >>> Andrés > > > > > >> Beware that these values are an underestimate for large objects and for > >>> fixed space objects. An object contains a small size field, and if its size > >>> won't fit in that field another word is allocated in front of the object > >>> which holds its full size. > > > >> In the 32-bit system the size is 11 bits and is a byte size. If the byte > >> size is >= (2^11)-32 it has an overflow word. i.e. >= 2016 bytes or >= 504 > >> inst vars. > > >> In the 64-bit system the size is 8 bytes and is a 64-bit word size. If the > >> word size is >= (2^8)-4 it has an overflow word. i.e. >= 2016 bytes or >= > >> 252 inst vars. > > >> The reserved size values are used to tag objects in fixed space. These > >> always have an extra size word (and a further 5 (count 'em and weep)) words > >> of overhead, which is bytesPerFTE. > > >> This information should be included in an ObjectMemory (the width of the > >> small size field, whether the small size field is words or bytes, and the > >> number of reserved values in the size field). But I hadn't got around to it > >> when I left Cincom. You could hard-code the above values if you want > >> accurate size estimates. > > >> HTH > >> Eliot > > >> Eliot Miranda escribió: > >>>> On Tue, Oct 20, 2009 at 8:59 AM, andres <[hidden email] > >>>> wrote: > > >>>>> Hi list, > >>>>> I need to estimate the size of a data structure in memory and > >>>>> I realized I don't know how much does the header of an object weight or > >>>>> how much memory is used for every i.v. (32bits?) Is this information > >>>>> available in the documentation? In particular i would need to know: > >>>>> - What is the weight of an object without any i.v. (e.g. Object new). > >>>>> - What is the size of each i.v. pointer. > > >>>>> Any hints are most welcome. > > >>>> There are methods in ObjectMemory which answer these questions. See > >>>> ObjectMemory protocol utilities. > > > > >>>>> -- > >>>>> Thanks in advance, > >>>>> Andrés > >>>>> _______________________________________________ > >>>>> vwnc mailing list > >>>>> [hidden email] > >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > >>>> ------------------------------------------------------------------------ > > >>>> _______________________________________________ > >>>> vwnc mailing list > >>>> [hidden email] > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >>> _______________________________________________ > >>> vwnc mailing list > >>> [hidden email] > >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > IMPORTANT NOTICE > Email from OOCL is confidential and may be legally privileged. If it is not > intended for you, please delete it immediately unread. The internet > cannot guarantee that this communication is free of viruses, interception > or interference and anyone who communicates with us by email is taken > to accept the risks in doing so. Without limitation, OOCL and its affiliates > accept no liability whatsoever and howsoever arising in connection with > the use of this email. Under no circumstances shall this email constitute > a binding agreement to carry or for provision of carriage services by OOCL, > which is subject to the availability of carrier's equipment and vessels and > the terms and conditions of OOCL's standard bill of lading which is also > available at http://www.oocl.com. > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |