[Openmcl-devel] memory

[Tim Bradshaw]

On 13 Apr 2010, at 15:02, Daniel Weinreb wrote:

> Tim, Gary,
>
> Tim Bradshaw wrote:
>>
>> .. and that's more-or-less the problem I came up with.  An   
>> implementation could, I think, provide some kind of "map-function- 
>> over- all-the-objects-this-thing-refers-to" function.
> I agree.  How about a generic function that takes
> object X and tells you (1) the size of the X, including all
> of the Lisp objects that make up X logically, and (2) all of
> the objects X refers to?


I'd like to see this, too, though I think two functions would be  
better than one:
* immediate-size-of (x) tells you the size of x in some arbitrarily  
defined units (which will always be bytes in practice)
* mapc-referents-of (f x) calls f on everything refers to and returns x.

I don't care what the names are, of course (except, not map-* since we  
deliberately want to not return the list of referents).

>>
> You mean, what if there is double-counting because
> object A refers to object B by more than one path?

Yes, and I agree that this is a caller problem, and they need to use  
an occurs check which they implement.

> The generic function hides things like how hash tables
> are implemented, just as generic functions can hide
> other things about the implementation. Is that
> good enough?

I'm thinking of the case where there is significant shared structure  
which should not be exposed: immediate-size-of will then overcount the  
memory when it looks at multiple objects which are sharing this secret  
stuff.

I actually would vote to just not worry about that: probably this  
secret-but-shared stuff is small.

>
> One potential problem here is that if your data structure
> uses symbols, it might be particularly hard to decide
> whether your data structure is "responsible" for the
> symbol, or whether the symbol was already created
> anyway.
>


Yes, there are many problems here I think.