[Openmcl-devel] memory

[Daniel Weinreb]

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?

By "tells you", I mean it could either return these
things, or call a function on them.  For example,
it could take a function as an argument, call
that on all the referenced objects, and return
the size of this (logical) object.

CCL could define methods for
that generic function on such types as hash tables
and closures. CCL knows all
the primitive-objects that the hash table is
made of and would not expose that to the caller.

Also, the application would define its own such
generic methods. The method can make its
own decisions about which referenced object
to follow, and which not to follow, and which
count as part of the size and which don't.


>   But that has at least  
> two problems: how does the user of that function know which of these  
> objects are ones they already know about and which are genuinely new?  
>   
You mean, what if there is double-counting because
object A refers to object B by more than one path?

Yes, that's a problem.  I'd say that the proposed generic
function would not worry about this; it would be the
caller's responsibility.  The caller might "know" that
there aren't any cases of this in his own class, for
example, or otherwise be able to avoid the general
duplicate-elimination problem by use of higher-level
knowledge about an object.  Otherwise, I think you
have to have an eq hash table to keep track of
which objects have been seen already, which of
course is cost in time and space.

Suppose your data structure includes symbols,
and you use their property lists.  But you don't
use their values, and some might have values
because they were already interned and someone
else used them.  In that case, your method would
call the generic function but ignore the "what
does the object reference", and instead call
the generic function directly on the property list.

> and, what about objects that something refers to which should be  
> genuinely secret (perhaps they're not safe for user code to even refer  
> to or something like that)? 
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?

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.


>  I suppose the first of these could be  
> solved by user code doing an EQ check (which it will need to do anyway  
> to avoid double-counting and loops).  The second I'm not sure about -  
> you could include the really-secret stuff in the basic size of the  
> object (what SIZEOF) returns, but what if some of that is shared?
>
> I don't think any of this is easy, at all.  It's mostly the same as  
> the answer to "why isn't there a general object copier in Lisp?",  
> except this is a bit harder.
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>