gb at clozure.com
Wed Apr 14 23:45:11 UTC 2010
Hmm. So one SIZEOF doesn't fit all ?
There are other names that one could use, but one convention (used
in the function HEAP-UTILIZATION and elsewhere) is to call "the size,
in bytes, of the accessible data in an object" its LOGICAL-SIZE
and the the size of the data + any header + alignment its PHYSICAL-SIZE.
You could also make one function that returns two values, or otherwise
structure this differently.
(defun logical-sizeof (thing)
;; All memory-allocated objects in CCL are either CONSes or
;; "UVECTOR"s; a UVECTOR contains a header which describes the
;; object's primitive type (represented as an (UNSIGNED-BYTE 8) and
;; accessible via the function CCL::TYPECODE) and element-count
;; (accessible via the function CCL::UVSIZE.) A function defined in
;; the compiler backend knows how to map from a typecode and
;; element-count to a size in octets.
;; On x86-64, SYMBOLs and FUNCTIONs have their own tag, but there's
;; an underlying UVECTOR.
(cond ((null thing) 0)
((consp thing) target::cons.size)
#+x8664-target ((and thing (symbolp thing)) (logical-sizeof (%symptr->symvector thing)))
#+x8664-target ((functionp thing) (logical-sizeof (function-to-function-vector thing)))
(let* ((typecode (typecode thing))
(element-count (uvsize thing)))
;; Call the architecture-specific backend function.
(defun physical-sizeof (thing)
;; For non-uvectors, the physical size is the same as the logical size.
;; For uvectors, the physical size includes header & alignment overhead.
;; On x8664, SYMBOLs and FUNCTIONs are conceptually uvevtors, but have
;; their own tag; we map them to the underlying uvector in the cond.
(let* ((logical-size (logical-sizeof thing)))
#+x8664-target ((and thing (symbolp thing)) (physical-sizeof (%symptr->symvector thing)))
#+x8664-target ((functionp thing) (physical-sizeof (function-to-function-vector thing)))
;; if thing is a UVECTOR, account for header and alignment,
(logandc2 (+ logical-size
target::node-size ; size of header
(1- target::dnode-size)) ; alignment
On Thu, 15 Apr 2010, Toomas Altosaar wrote:
>> Message: 5
>> Date: Wed, 14 Apr 2010 15:23:44 +0100
>> From: Tim Bradshaw <tfb at tfeb.org>
>> Subject: Re: [Openmcl-devel] memory
>> To: Alexander Repenning <ralex at cs.colorado.edu>
>> Cc: openmcl-devel Devel <openmcl-devel at clozure.com>
>> Message-ID: <BC113436-4CA0-4C0F-9BBA-106E7425DC6F at tfeb.org>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>> On 14 Apr 2010, at 14:58, Alexander Repenning wrote:
>>> 2) sizeof as C/C++/Ojective-C inspired sizeof operator returning the
>>> number of RAW bytes with no meta information (no headers, no tag
>>> bits, ...) typically used to deal with FFIs. Mostly used in the
>>> context of allocating raw memory and accessing it with (%get-
>>> byte ...) kinds of functions.This is what we need to interface with
>>> OpenGL/ Cocoa and other APIs on Macs and PCs.
>> How is this useful?
> Let's say you want to copy some data from the Lisp to a framework
> you've written in C. For this you need to know how many 8 bit bytes
> need to be reserved on the heap. You do not want to include Lisp
>> I want SIZEOF to tell me how many instances of an
>> x I can fit in y bytes of memory, not some number which tells me
>> something I can't see a use for.
> Others can see a very definite use for it.
>> For this version of sizeof, what would, say (sizeof (make-
>> instance ...)) be useful for?
> I can envision many.
> For example, the same as above: take the case where you wish to
> mirror all the non-LISP specific implementation data in your instance
> through an FFI to and from a framework. This version will give you a
> lower bound as to how much memory requires reserving.
> Another example: let's say you wish to estimate how much
> memory/bandwidth/time is required for the serialization of a compound
> Lisp object between two (LISP) nodes located in remote locations on
> some network, assuming already that the other node is running the
> same version and has the same class definitions on hand. Without
> knowing the RAW number of bytes you will not be able to make an
>> Perhaps your objection is that this thing should not be called sizeof
>> because it's too reminiscent of the C function.
> I would object as well; it is much easier to expect a similarly named
> function to do the same thing across languages than to remember the
> I don't think it should be too much of a strain on LISP users to come
> up with a more descriptive and more suitable name than what is used
> in C.
> This function's operation - whatever it will be called - is
> definitely implementation and version specific.
> Memory-footprint, Lisp-footprint, or something shorter and catchier?
> What do other LISP implementations call it?
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel