Hi Lispers,
This is an old one but I haven't been able to find a solution and
have no references to find the state of the art.
To explain:
An example of a common requirement in CLOS programs
is to memoize instances of a class (usally in the class metaobject);
since this usually requires stuffing objects onto a list in the class
these objects are thus prevented from otherwise being gc'd.
This serves to highlight a general omission from CL, that is the
notion of weak binding, what I mean here is a binding that may
be undone (unbound) automatically and the relevant object then
becoming eligible for gc'ing should only other weak or no other
bindings exist. In other words a weak binding would not increment
any reference count and additionally would be undone silently
should the object be gc'd.
The question is: Is there a way to implement this portably
in common-lisp? My gut feel for this is no, otherwise I guess
I'd be using it and not posting here. I suppose various
implementations might offer some access to underlying gc controls.
I have often thought that lisp should offer some control over
storage parameters on a per object basis, maybe this would be
an opportunity to open up lisp storage managment via a MOP or
whatever.
Any thoughts, ideas, experience or wisdom?
/simon
In article <··········@xenon.bt-sys.bt.co.uk>, Simon Beaumont
<··············@bt-sys.bt.co.uk> wrote:
> This is an old one but I haven't been able to find a solution and
> have no references to find the state of the art.
>
> To explain:
> An example of a common requirement in CLOS programs
> is to memoize instances of a class (usally in the class metaobject);
> since this usually requires stuffing objects onto a list in the class
> these objects are thus prevented from otherwise being gc'd.
>
> This serves to highlight a general omission from CL, that is the
> notion of weak binding, what I mean here is a binding that may
> be undone (unbound) automatically and the relevant object then
> becoming eligible for gc'ing should only other weak or no other
> bindings exist. In other words a weak binding would not increment
> any reference count and additionally would be undone silently
> should the object be gc'd.
>
> The question is: Is there a way to implement this portably
> in common-lisp? My gut feel for this is no, otherwise I guess
> I'd be using it and not posting here. I suppose various
> implementations might offer some access to underlying gc controls.
> I have often thought that lisp should offer some control over
> storage parameters on a per object basis, maybe this would be
> an opportunity to open up lisp storage managment via a MOP or
> whatever.
I'm not aware of any _portable_ way to do this. Maclisp had
'non-gc'd' arrays, which were used for implementing 'weak pointers'
for AI programs. These required conspiring with a 'gc-daemon', which
was a user-level program that ran at the end of every gc.
I have been told that MIT Multilisp/Multischeme had some form of weak
pointer capability as well.
The notion of a 'weak symbol' in linking loaders is essentially identical
to the notion of a weak pointer. A weak symbol is incapable of loading
a subroutine from a library on its own, but if the subroutine is loaded
via a 'strong symbol', then the weak symbol will be appropriately updated.
Otherwise, it is zero. 'Weak symbols' are used in at least Unix SVR4, and
go back perhaps 30 years to early IBM linking loaders.
--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
In article <··········@xenon.bt-sys.bt.co.uk> Simon Beaumont <··············@bt-sys.bt.co.uk> writes:
>This serves to highlight a general omission from CL, that is the
>notion of weak binding, what I mean here is a binding that may
>be undone (unbound) automatically and the relevant object then
>becoming eligible for gc'ing should only other weak or no other
>bindings exist. In other words a weak binding would not increment
>any reference count and additionally would be undone silently
>should the object be gc'd.
Several Lisp implementatations provide this in some form or another these
days. It's a relatively recent addition to most Lisps, and wasn't common
when Common Lisp was being designed, which explains why it isn't included
in the CL specification.
Lucid CL has weak lists and weak hash tables. In weak hash tables, the
links to the keys are weak, and if the key is GCed the reference to the
corresponding value is removed.
--
Barry Margolin
BBN PlaNET Corporation, Cambridge, MA
······@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-5124
In article <··········@xenon.bt-sys.bt.co.uk>, Simon Beaumont <··············@bt-sys.bt.co.uk> writes:
>>
>> This serves to highlight a general omission from CL, that is the
>> notion of weak binding, what I mean here is a binding that may
>> be undone (unbound) automatically and the relevant object then
>> becoming eligible for gc'ing should only other weak or no other
>> bindings exist. In other words a weak binding would not increment
>> any reference count and additionally would be undone silently
>> should the object be gc'd.
>>
>> The question is: Is there a way to implement this portably
>> in common-lisp? My gut feel for this is no, otherwise I guess
>> I'd be using it and not posting here. I suppose various
It isn't possible implement this yourself. I believe they are called
"weak pointers". Allegro CL/Unix has weak vectors as a documented extension.
We use them to implement weak hashtables for AllegroStore to maintain
EQness of instances accessed from a database. An instance will get GC'd
if the only reference to one is in the table.
It isn't clear how they should be put in the standard.
Weak-vectors? weak-lists? weak-tables? weak-pointers?
All of the above?
What do you want to use them for?
>> implementations might offer some access to underlying gc controls.
>> I have often thought that lisp should offer some control over
>> storage parameters on a per object basis, maybe this would be
>> an opportunity to open up lisp storage managment via a MOP or
>> whatever.
>>
>> Any thoughts, ideas, experience or wisdom?
>>
per-object basis would indicate they are part of the object,
but they are part of the reference to an object. This is why
you get weak-lists, vectors, etc.
You could have something called
a weak-pointer that is wrapper around an object that looks like
the real object, but becomes NIL if no strong refrences exists.
Something like (weak-pointer #<foo>) --> #<foo> w/magic disappearing act
This would be a general solution, so you can do:
(defun weak-list (&rest objects) (mapcar #'weak-pointer objects))
This would require something like forwarding-pointers though,
which isn't easy and isn't cheap.
-Kelly Murray ···@franz.com http://www.franz.com
Thanks to those who replied by mail and pointed me at weak hash
tables. This is not part of standard common-lisp however
Allegro CL/PC at least has an undocumented keyword arg (NKIND 0)
which might well be a switch to make 'em weak.
Be damned useful if it is.
So can you all please check your implementations of make-hash-table
for likely looking parameters and I'll promise to find out and
summarise which/how implementations handle this if at all.
/simon
Simon Beaumont <··············@bt-sys.bt.co.uk> writes:
This serves to highlight a general omission from CL ...
In other words a weak binding would not increment
any reference count and additionally would be undone silently
should the object be gc'd. ^^^^^^^^
What is more frequently needed in my experience is the ability to
call a specified hook when an object is about to be GC'ed. Some built-in
like this:
(ADD-DESTRUCTOR object function)
has the effect that when the object is about to be garbage-collected,
the function gets called with object as argument.
Of course, the collection of the object does not take place until the
function has done its job and released the object, so that the next GC
can take it away.
Some extension of this, which can be used to implement weak pointers,
is the following:
(ADD-DESTRUCTOR object function guardian)
has the effect that when the object is about to be garbage-collected
and the guardian has not yet been garbage-collected, then
the function gets called with object and guardian as arguments.
If the guardian dies before the object, the function does not get called.
----------------------------------------------------------------------------
Bruno Haible net: <······@ilog.fr>
ILOG S.A. tel: +33 1 4908 3585
9, rue de Verdun - BP 85 fax: +33 1 4908 3510
94253 Gentilly Cedex url: http://www.ilog.fr/
France url: http://www.ilog.com/