[Openmcl-devel] memory

[Gary Byers]

A STANDARD-INSTANCE stores the values of its instance slots in a special
kind of vector called a "slot-vector"; this indirection is necessary, since
an instance's class can be redefined or changed (and thus the number of
slots can change.)  There are a couple of other fields (besides the slot-vector)
in the instance itself, but they aren't very interesting.

You can obtain an instance's slot-vector via:

? (ccl::instance-slots instance)

(This works on instances of STANDARD-OBJECT, FUNCALLABLE-STANDARD-OBJECT,
and on instances of ObjC classes and metaclasses in the ObjC bridge.)

If you use the SIZEOF function that I mailed out yesterday, then the total
size of an instance of STANDARD-OBJECT is basically:

(+ (ccl::sizeof instance) (ccl::sizeof (ccl::instance-slots instance)))

You should be able to come pretty close to the same result by doing:

1) call CLASS-SLOTS on the instance's class; count the number of
    slot-definitions whose SLOT-DEFINITION-ALLOCATION is :INSTANCE.
2) Add 2 to that number (the header on the slot-vector and a backpointer
    to the instance.)  If the result is odd, add 1 to make it even.
3) Add 4 to the result obtained in step (2).  (This accounts for the
    instance itself and its header.)
4) Shift the result obtained in step (3) to the left by TARGET::WORD-SHIFT
    bits (e.g., multiply by 4 or 8, depending on the native word size.)

At some level, this is what (SIZEOF some-standard-instance) should do for
you, since at some level the fact that the instance and its slot-vector
are disjoint is just an implementation artifact.  At another level,  the
instance and its slot-vector are disjoint objects, and SIZEOF should 
avoid policy decisions and simply return the size of a primitive object.

If anyone finds themselves to be unaccountably interested in the details
of object representation in CCL, the files:

    ccl/library/lispequ.lisp
    ccl/compiler/**/*-arch.lisp

will either make fascinating reading or permanently cure them of that
interest.



On Tue, 13 Apr 2010, Joakim Sandgren wrote:

> Thank you Gary.So now I can "count" all the final values in an instance.
> Does the instance itself take any memory? how much that is...
> 
> If I have an instance like
> 
> (class
> (slot1 value 12)
> (slot2 value "zer")
> (slot3 value nil)
> (slot4 value 4.3456)
> (slot5 value "normal"))
> 
> I'd be able to count the 12 "zer" 4.3456 and "normal"
> 
> but not the instance itself. 
> how much does it take in memory to administrate a slot ? 
> that is an instance of the slotdefinition class ?
> if I dont use any accessors readres or writers. (only slot-value for
> everthing)
> 
> thank you again.
> 
> very sincerely
> joakim
> 
> 
> Le 13 avr. 10 à 12:42, Gary Byers a écrit :
> 
> 
>
>       On Tue, 13 Apr 2010, Joakim Sandgren wrote:
>
>             This I could do. I already make my own "deep-copy"
>             functions.With the Sizeof
>
>             function proposed by A. Repenning it could give me
>             an idea of a size.
>
>             I think I could try to handle myself the case where
>             I have the real instance
>
>             or a pointer. 
>
>             I think its quite "tactile" my object. I have staff,
>             section, partial
>
>             section, measure, partial measure ,note group,
>             note. 
>
>             all these are (what I understand) "real" instances.
>             but then for example in
>
>             the notes I have next note and preceding note, wich
>             is then referenced. 
>
>             so when I do the walker I dont look at them...
>
>             And in the end in all the slots there are integers
>             or floats..., or Strings.
>
>             How do I get the size of a string ? length * x.
> 
>
>       The SIZEOF a SIMPLE-STRING is its length * 4, + the size of a
>       header (4 bytes
>       in 32-bit CCL, 8 bytes in 64-bit CCL), rounded up to an object
>       alignment boundary
>       (8/16 bytes.)  The SIZEOF function that I mailed out yesterday
>       should know how
>       compute this value.
>
>       For STRINGs that aren't SIMPLE-STRINGs, the answer's more
>       complicated.  The
>       STRING will be a fixed-sized object that (possibly transitively)
>       refers
>       to some SIMPLE-STRING.  SIZEOF would return a consistent answer
>       on such
>       a string (whatever that answer is depends on word size), but it
>       may not
>       be a particularly interesting answer (and would have nothing to
>       do with
>       the length of the string.)
>
>       This probably counts as another example of a "somewhat opaque
>       implementation-
>       level data structure."
>
>             Very sincerely
>
>             Joakim
> 
> 
> 
> 
> 
> Joakim Sandgren
> joakim sandgren musik
> 42, rue de Maubeuge
> 75009 Paris
> France
> +33 (0)1 45 26 43 90
> info at joakimsandgren.com
> http://www.joakimsandgren.com
> 
> 
>