[Openmcl-devel] memory

[Gary Byers]

On Mon, 12 Apr 2010, Tim Bradshaw wrote:

> On 12 Apr 2010, at 22:32, Gary Byers wrote:
>
>> If you don't need to handle these kinds of cases, then yes, the hard part 
>> is
>> knowing how to obtain the size of some primitive object.
>
> I agree completely with the text I elided - the difficult bit of this kind of 
> thing is walking the structure, dealing with sharing & circularities etc. 
> *However* that is generally code that the user is able to write without 
> dependencies on the internals of the implementation (and indeed it's code 
> that *only* they can write as it depends on their knowledge of what stuff 
> counts for them).  I think the sizeof primitive is something reasonably 
> important, because it's the bit you *can't* write without understanding the 
> implementation.
>

(let* ((thing (make-really-big-thing)))
   (make-instance 'my-class :thing-closure (lambda (x) (do-something-with x thing))
                            ...))

You don't have a portable way of examining the things in a closure's environment
(or the constants referenced by a non-closure function.)  Whether or not it's
desirable to walk a closure or other function requires some application-specific
knowledge.  (In this example, the closure's uniquely referenced and it closes
over something that's presumably a Really Big Thing; one's notion of the memory
cost of that instance would likely be grossly incorrect unless the Really Big
Thing referenced by the closure was processed.)

Feel free to substitute "largely opaque primitive object" for "closure"; I don't
think that it's uncommon for user-defined data structures to contain primitive
data structures.  CONSes are "primitive data structures" that aren't exactly
opaque; HASH-TABLEs are somewhat more opaque (you can enumerate their contents
via MAPHASH, but HASH-TABLE-SIZE doesn't necessarily reflect the SIZEOF the
hash table itself), the opacity of closures and functions in CCL depends on
the platform (and is inherently pretty implementation-dependent) ...

So ... you could possibly handle these cases if the implementation provided
some means of enumerating a primitive object's "direct" contents.  That's certainly
doable (and could be useful in other contexts), but using such primitives seems
to require that the user understand at least some implementation-level concepts
(even if they don't need to know the details.)  I'm not sure that I understand
exactly what this means in practice, but I'm not sure that even experienced users
have (or want, or otherwise need to have) that understanding.

If I had any lingering doubts about whether SIZEOF needs to be done in the
implementation ... well, let's just say that I've seen convincing evidence
that argues that it does indeed belong there.