gb at clozure.com
Tue Apr 13 05:28:32 PDT 2010
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:
will either make fascinating reading or permanently cure them of that
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
> (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
> thank you again.
> very sincerely
> 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,
> 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)
> 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
> level data structure."
> Very sincerely
> Joakim Sandgren
> joakim sandgren musik
> 42, rue de Maubeuge
> 75009 Paris
> +33 (0)1 45 26 43 90
> info at joakimsandgren.com
More information about the Openmcl-devel