I've always thought that some kind of weak reference would be a nice
thing to have in CL. But I'm not really fluent enough in GC
technology to know what the implications are. It's also not
completely clear to me how to do them, because you really want the
thing that does the reference to be very small -- preferably just a
pointer, not a structure with slots. Alternatively you could do weak
tables of some kind (and if you have weak hashtables you can fake weak
references by keeping integer keys around, if you don't mind the
performance hit).
The kind of things I would find them useful for are where you have
some dependency protocol, where an object needs to tell a bunch of
dependents about something, but you don't want to have to do
essentially manual memory management of the dependents, to avoid the
master object from hanging on to references to them for ever.
Anyway, does anyone who knows about GCs in detail know what the
implications of these are?
Which of the commercial (and non commercial) CLs have weak references
of some kind (or weak hashtables, or ...)? The only one I can answer
for at the moment, for what its worth, is Genera, which has weak
hashtables.
Thanks
--tim
This is a multi-part message in MIME format.
--------------83C48630A6F95C5018B75CC5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tim Bradshaw wrote:
> Which of the commercial (and non commercial) CLs have weak references
> of some kind (or weak hashtables, or ...)? The only one I can answer
> for at the moment, for what its worth, is Genera, which has weak
> hashtables.
ACL and Lispworks have weak references. Some years ago, when
I needed weak hash tables, the guys at Franz provided
m extremely quickly with an implementation.
Later on, I grabbed the hashtable implementation from CMU CL
and tweaked it to implement weak hash tables on Lispworks.
--------------83C48630A6F95C5018B75CC5
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fernando Mato Mira
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Fernando Mato Mira
n: Mato Mira;Fernando
email;internet: ········@iname.com
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------83C48630A6F95C5018B75CC5--
This is a multi-part message in MIME format.
--------------558BC9FA37B2C398A93F477B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
BTW, Boehm GC supports weak pointers, so any language based
on it has no reason not to offer such a facility to the user.
--------------558BC9FA37B2C398A93F477B
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fernando Mato Mira
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Fernando Mato Mira
n: Mato Mira;Fernando
email;internet: ········@iname.com
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------558BC9FA37B2C398A93F477B--
Fernando D. Mato Mira wrote:
>
> BTW, Boehm GC supports weak pointers, so any language based
> on it has no reason not to offer such a facility to the user.
Except time for design, documentation, debugging, support, ....
- Howard Stearns, product manager for Eclipse, which happens to use
Boehm GC, but which does not currently provide finalization support from
Lisp. (Though of course, it is available from C within the same
application, but then you have to use the Boehm GC "documentation"....)
"Howard R. Stearns" <······@elwood.com> writes:
> - Howard Stearns, product manager for Eclipse, which happens to use
> Boehm GC, but which does not currently provide finalization support from
> Lisp. (Though of course, it is available from C within the same
> application, but then you have to use the Boehm GC "documentation"....)
I think finalisztion support is different, isn't it? I've always thought
adding finalisation was a much harder and more obscure thing to do than
weak pointers. Really, a weak pointer just says `this thing might
become NIL sometime, if you want to keep it you need to be stronger'
(and in particular it might *not* vanish, for instance if it's been
tenured), while a finalisation system implies all sorts of things
including dealing with something that is almost garbage suddenly
not being any more, and probably something which is not garbage
but which has garbage slots.
Really, I think weak pointers constrain the GC much less, and that
is a good thing to do (though they may already constrain it too
much).
I'd much rather have weak pointers than finalisation. Again, I'd like
to hear from people who do real implementations to know what the
merits & costs are.
--tim
>>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:
Tim> Which of the commercial (and non commercial) CLs have weak references
Tim> of some kind (or weak hashtables, or ...)? The only one I can answer
CMUCL has weak pointers.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:
>
> Tim> Which of the commercial (and non commercial) CLs have weak references
> Tim> of some kind (or weak hashtables, or ...)? The only one I can answer
>
> CMUCL has weak pointers.
>
Yes, but... it is not all that clear how to use them. At least I - in
my ignorance - have not figured out a strightforward way to use them.
AFAIU, in order to make a weak hash table in CMUCL you do
* (defvar wht (make-hash-table :test #'eq :weak-p t))
* Creating unsupported weak-p hash table
WHT
* (defvar the-object "I will be pointed to by a weak reference")
THE-OBJECT
* (defvar wp (make-weak-pointer the-object))
WP
* (setf the-object nil)
NIL
* (setf (gethash wp wht) 123)
123
* (gethash wp wht)
123
T
*
Which, IMHO brings up a not so nice stylistical problem. I.e., this
seems to me that we are just moving the problem somewhere
else. I.e. if I have a set of objects, which may grow or shrink, and I
have a set of associations from these objects to some other set of
elements (kept in a weak hash tables), I now have the problem of
managing the set of weak pointers.
If I am mistaken I will be glad to be enlightened.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it
I would be leary of using constants for this, since they may be handled
specially by the lisp system. Do you get the same behavior if you start
with
(defvar the-object (make-list 3))
?
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
Marco Antoniotti <·······@copernico.parades.rm.cnr.it > writes:
> * (defvar wht (make-hash-table :test #'eq :weak-p t))
> * Creating unsupported weak-p hash table
> WHT
> * (defvar the-object "I will be pointed to by a weak reference")
> THE-OBJECT
> * (defvar wp (make-weak-pointer the-object))
> WP
> * (setf the-object nil)
> NIL
> * (setf (gethash wp wht) 123)
> 123
> * (gethash wp wht)
> 123
> T
I would also expect that you need one or maybe even two GCs to intervene
before the object pointed to by the weak pointer goes away.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
In article <···············@tfeb.org> , Tim Bradshaw <···@tfeb.org> wrote:
> I've always thought that some kind of weak reference would be a nice
> thing to have in CL. But I'm not really fluent enough in GC
> technology to know what the implications are. It's also not
> completely clear to me how to do them, because you really want the
> thing that does the reference to be very small -- preferably just a
> pointer, not a structure with slots. Alternatively you could do weak
> tables of some kind (and if you have weak hashtables you can fake weak
> references by keeping integer keys around, if you don't mind the
> performance hit).
>
> The kind of things I would find them useful for are where you have
> some dependency protocol, where an object needs to tell a bunch of
> dependents about something, but you don't want to have to do
> essentially manual memory management of the dependents, to avoid the
> master object from hanging on to references to them for ever.
>
> Anyway, does anyone who knows about GCs in detail know what the
> implications of these are?
>
> Which of the commercial (and non commercial) CLs have weak references
> of some kind (or weak hashtables, or ...)? The only one I can answer
> for at the moment, for what its worth, is Genera, which has weak
> hashtables.
MCL supports weak hash tables.
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
In article <···············@tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
>
> Which of the commercial (and non commercial) CLs have weak references
> of some kind (or weak hashtables, or ...)? The only one I can answer
> for at the moment, for what its worth, is Genera, which has weak
> hashtables.
>
Corman Lisp provides weak references. (See http://corman.net/CormanLisp.html)
Implementing these in a generational GC was not too tricky. It just
requires that the reference scanning functions can tell a weak reference
from a normal one, and avoid using it to keep an object alive. However,
a weak poiner does need to be updated if the object is kept alive by another
non-weak reference. Therefore, another pass is needed after the main
scan/update pass (for each generation) to either update or set to NIL
any weak pointers in that generation. To avoid the overhead of a second
complete scan, I decided to maintain an internal list (which only the
collector knows about) of weak pointers. Then this list can be scanned
and updated appropriately as a phase of the collection process.
Roger Corman
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Tim Bradshaw <···@tfeb.org> wrote:
> The kind of things I would find them useful for are where you have
> some dependency protocol, where an object needs to tell a bunch of
> dependents about something, but you don't want to have to do
> essentially manual memory management of the dependents, to avoid the
> master object from hanging on to references to them for ever.
Another similar kind of application, where you need them, is for
distributed garbage collection between, say, a C process and a Lisp
process.
> Anyway, does anyone who knows about GCs in detail know what the
> implications of these are?
In traditional and generational GCs, the cost is not high: You have
to special-case weak pointers at some points in the code.
I wouldn't know how to implement it for incremental GCs, however.
> Which of the commercial (and non commercial) CLs have weak references
> of some kind (or weak hashtables, or ...)?
CMUCL and CLISP have them (for CLISP, only recent snapshots), with the
following API:
(MAKE-WEAK-POINTER value) returns a fresh weak pointer referring to value.
(WEAK-POINTER-P object) returns true if the object is of type WEAK-POINTER.
(WEAK-POINTER-VALUE weak-pointer) returns two values: The original value and
T, if the value has not yet been garbage collected, else NIL and NIL.
Bruno http://clisp.cons.org/
Tim Bradshaw <···@tfeb.org> wrote in message
····················@tfeb.org...
...
>Which of the commercial (and non commercial) CLs have weak references
>of some kind (or weak hashtables, or ...)? The only one I can answer
>for at the moment, for what its worth, is Genera, which has weak
>hashtables.
Harlequin LispWorks for Windows has weak hashtables. They work well.
Marc Battyani
Tim Bradshaw <···@tfeb.org> writes:
> I've always thought that some kind of weak reference would be a nice
> thing to have in CL. [...]
> Anyway, does anyone who knows about GCs in detail know what the
> implications of these are?
>
> Which of the commercial (and non commercial) CLs have weak references
> of some kind (or weak hashtables, or ...)? The only one I can answer
> for at the moment, for what its worth, is Genera, which has weak
> hashtables.
Allegro CL implements several kinds of weak references, from simple
arrays and hash-tables. It also implements finalizations
(allowing a lisp action to be taken upon the impending death of an
object).
See the chapter "10.0 Weak vectors, finalizations, static arrays, etc."
in http://www.franz.com/support/docs/5.0/doc/cl/gc.htm
Also, see the chapter "5.5 cl:make-hash-table" in
http://www.franz.com/support/docs/5.0/doc/cl/implementation.htm
Weak vectors are not hard to implement. There are two down sides
implementationally:
1. An object that has weak pointers must be examined periodically,
and thus is anti-ephemeral/anti-generational-gc - it needs
attention every gc, no matter how old it gets. Thus, it is
better to allocate fewer numbers of larger weak vectors than
larger numbers of smaller objects; the generational gc will tend
to be more efficient.
2. It's very hard to _guarantee_ that an object will be no longer
pointed to after the usual operations on it are done; there is
of course the infamous "I thought I broke that link" pointer to
the object, the "I'm a debugger and I'll hold on to your data"
reference, and the much more subtle "I'm a dead slot in an
otherwise active stack frame in another thread" pointer, all
of which will cause a surprising tenacity of the object that
should have been be collected away.
Finalizations are much harder to implement, because of the requirement
that the finalization receive the object scheduled for death. This
means that the object must be copied in spite of its being unreferenced
(remember, copying and generational gcs are not garbage _collectors_
but garbage _leavers_; instead the live data is copied). The death
must come after the finalization is run, but the gc must not mark the
object for later death (the finalization could easily place the object
on a global list, thereby resurrecting it).
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>Finalizations are much harder to implement, because of the requirement
>that the finalization receive the object scheduled for death. This
>means that the object must be copied in spite of its being unreferenced
>(remember, copying and generational gcs are not garbage _collectors_
>but garbage _leavers_; instead the live data is copied). The death
>must come after the finalization is run, but the gc must not mark the
>object for later death (the finalization could easily place the object
>on a global list, thereby resurrecting it).
The list of objects requiring finalization should be a weak list, so that
the objects won't be copied during the normal pass of the GC. After that,
the GC should go through the finalization list. Any object that hasn't
been copied should be copied, removed from the list, and its finalization
function called. If the finalization function doesn't resurrect it, it
will be collected for real during the next pass of the GC.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@bbnplanet.com> writes:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> wrote:
> >Finalizations are much harder to implement, because of the requirement
> >that the finalization receive the object scheduled for death. This
> >means that the object must be copied in spite of its being unreferenced
> >(remember, copying and generational gcs are not garbage _collectors_
> >but garbage _leavers_; instead the live data is copied). The death
> >must come after the finalization is run, but the gc must not mark the
> >object for later death (the finalization could easily place the object
> >on a global list, thereby resurrecting it).
>
> The list of objects requiring finalization should be a weak list, so that
> the objects won't be copied during the normal pass of the GC. After that,
> the GC should go through the finalization list. Any object that hasn't
> been copied should be copied, removed from the list, and its finalization
> function called. If the finalization function doesn't resurrect it, it
> will be collected for real during the next pass of the GC.
Correct; I overstated it when I said it was "much harder"; really it is
slightly harder because it involves an extra copying pass.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Tim Bradshaw <···@tfeb.org> writes:
I wrote
>
> Which of the commercial (and non commercial) CLs have weak references
> of some kind (or weak hashtables, or ...)? The only one I can answer
> for at the moment, for what its worth, is Genera, which has weak
> hashtables.
>
And the answer so far is ACL, Lispworks, Corman CL, CMUCL (and Genera
for what it is worth) have weak somethings I think. Anyone know about
MCL? GCL? And Eclipse does not have them, if I read Howard right.
I guess this means that I can almost assume they exist, which is cool!
--tim
Tim Bradshaw <···@tfeb.org> writes:
> >
> > Which of the commercial (and non commercial) CLs have weak references
> > of some kind (or weak hashtables, or ...)? The only one I can answer
> > for at the moment, for what its worth, is Genera, which has weak
> > hashtables.
> >
>
> And the answer so far is ACL, Lispworks, Corman CL, CMUCL (and Genera
> for what it is worth) have weak somethings I think. Anyone know about
> MCL? GCL? And Eclipse does not have them, if I read Howard right.
>
MCL has weak hash tables and finalization (which it calls termination).
-matt
Tim Bradshaw <···@tfeb.org> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> I wrote
> >
> > Which of the commercial (and non commercial) CLs have weak references
> > of some kind (or weak hashtables, or ...)? The only one I can answer
> > for at the moment, for what its worth, is Genera, which has weak
> > hashtables.
> >
>
> And the answer so far is ACL, Lispworks, Corman CL, CMUCL (and
> Genera for what it is worth) have weak somethings I think. Anyone
> know about MCL? GCL? And Eclipse does not have them, if I read
> Howard right.
XEmacs Lisp has weak hashtables and weak lists.
(I hope this appears after my previous message, the news server I use currently
seems to take half an hour to list articles posted locally...)
And I should not have omitted CLISP, and Lucid/Liquid I suppose -- anyone
know what they offer?
Thanks
--tim
Tim Bradshaw <···@tfeb.org> writes:
> And I should not have omitted CLISP, and Lucid/Liquid I suppose -- anyone
> know what they offer?
Liquid CL has weak hash tables and weak sets.
--
Pekka P. Pirinen Harlequin Group plc
The Memory Management Reference: articles, bibliography, glossary, news
<URL:http://www.harlequin.com/mm/reference/>