[Openmcl-devel] calcultaing memory use.

Gary Byers gb at clozure.com
Mon Nov 15 11:55:15 PST 2004



On Mon, 15 Nov 2004, Marco Baringer wrote:

> Gary Byers <gb at clozure.com> writes:
>
> > Determining how much memory a given lisp object takes up is fairly
> > simple: conses are a pair of 32-bit words, everything else has a
> > 32-bit header on the front of it and everything is aligned on a
> > doubleword boundary.  (See the code attached to the message cited
> > above for details.)
>
> here's my main question:
>
> if "conses are pairs of 32 bits words, and everything else has a 32
> bit header, and everything is double word aligned" then the size of
> an array is it's length + 32 bits + the size of all non immediate
> objects it contains. a hash table is the size of its various
> properties (size, test, rehash count, etc.) + 32 bits + (* 2
> hash-table-size) + the size of all non immediate keys and values.
>
> if this analysis is right, is there a way to generalize this and work
> with the uvector instead of having to write multiple object traversal
> functions? (in particular i'd like to know how much "stuff" closures
> are forcing me to keep around and this is going to require some
> uvector walking.

The number of bytes in an object of type HASH-TABLE is 80 (I don't
know that off the top of my head, but I trust CLASSIFY-OBJECT ..).
That's 4 bytes for the header and either 72 or 76 bytes for either 18
or 19 internal slots (rehash info, locks, arcana ...), rounded up to a
multiple of 8 bytes (everything is aligned in memory on an 8-byte
boundary and zero-padded - if necessary - out to the next 8-byte
boundary.)

All objects of type HASH-TABLE are exactly the same size.  The key/
value pairs associated with the hash table are kept in a separate
object (of type CCL::HASH-TABLE-VECTOR).  The size of that vector
depends on the hash-table count (and rehash threshold, etc.)  If
items are added to/deleted from the hash table, the vector might
be replaced with a larger/smaller one.

>
> all of these questions, and the uvector walking idea, stem from the
> fact that your classify-object function, slighty modified to size of
> its argument[1], does this:
>
> CCL> (classify-object "a")
> 8
> SIMPLE-BASE-STRING
> CCL> (classify-object "abcde")
> 16
> SIMPLE-BASE-STRING
> CCL> (classify-object (make-hash-table :size 0))
> 80
> INTERNAL-STRUCTURE
> CCL> (classify-object (make-hash-table :size 1000))
> 80
> INTERNAL-STRUCTURE
>
> which is close to what i'm trying, but not quite there.

? (ccl::nhash.vector (make-hash-table))
#<HASH-TABLE-VECTOR #x6F88EB6>

Calling CLASSIFY-OBJECT on the HASH-TABLE-VECTOR should give you
different results (in general ...) for different hash tables.
(The HASH-TABLE-VECTOR has ~10-12 words of fixed-size overhead;
remaining indices are key/value pairs.)

Likewise: a STANDARD-INSTANCE is a small (3 word) UVECTOR; one of
those words points to a SLOTS-VECTOR which contains ... the values of
the instance's slots.  The size of the SLOTS-VECTOR depends on the
class of the instance (and may change if that class is redefined); the
instance itself is of fixed size.




More information about the Openmcl-devel mailing list