Hello,
recently there was a debate about using some subset of Lisp to write
a garbage collector aimed to be used afterwards in the
full language.
I wondered whether a lisp dialect working without garbage collection
already exists. From my experiences the GC is closely related to the
way of programming. So my search seems fruitless. :)
Regards,
Julian
--
Meine Hompage: http://julian.re6.de
Ich suche eine PCMCIA v1.x type I/II/III Netzwerkkarte.
Ich biete als Tauschobjekt eine v2 100MBit Karte in OVP.
From: Christopher C. Stacy
Subject: Re: Lisp without GC?
Date:
Message-ID: <ulm981kf1.fsf@grant.org>
>>>>> On 21 Jun 2002 18:29:36 +0200, Julian Stecklina ("Julian") writes:
Julian> Hello,
Julian> recently there was a debate about using some subset of Lisp to write
Julian> a garbage collector aimed to be used afterwards in the
Julian> full language.
Julian> I wondered whether a lisp dialect working without garbage collection
Julian> already exists. From my experiences the GC is closely related to the
Julian> way of programming. So my search seems fruitless. :)
Earlier versions of the Lisp Machine :)
······@grant.org (Christopher C. Stacy) writes:
> >>>>> On 21 Jun 2002 18:29:36 +0200, Julian Stecklina ("Julian") writes:
>
> Julian> Hello,
> Julian> recently there was a debate about using some subset of Lisp to write
> Julian> a garbage collector aimed to be used afterwards in the
> Julian> full language.
>
> Julian> I wondered whether a lisp dialect working without garbage collection
> Julian> already exists. From my experiences the GC is closely related to the
> Julian> way of programming. So my search seems fruitless. :)
>
> Earlier versions of the Lisp Machine :)
No, that doesn't count. The Lisp Machines had a *really* slow stop
and copy collector. You ran out of space? You save the world for six
hours, then come back when it's done and reboot. The very same
collector is available as an option on Exploders and Symbollix boxen.
No wait, it's not an option, it's bundled with the system.
Although not Lisp, the Scheme48 implementation is written in a
sporadically documented Scheme dialect called PureScheme which lacks
GC. All allocation and collection must be performed explicitly. If
you wanted a Lisp dialect you could probably base it off of a similar
set of primitives. Just make sure your primitives only cons on the
stack and then have one pair that works like malloc/free.
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
In article <·············@grant.org>,
Christopher C. Stacy <······@grant.org> wrote:
>>>>>> On 21 Jun 2002 18:29:36 +0200, Julian Stecklina ("Julian") writes:
>
> Julian> Hello,
> Julian> recently there was a debate about using some subset of Lisp to write
> Julian> a garbage collector aimed to be used afterwards in the
> Julian> full language.
>
> Julian> I wondered whether a lisp dialect working without garbage collection
> Julian> already exists. From my experiences the GC is closely related to the
> Julian> way of programming. So my search seems fruitless. :)
>
>Earlier versions of the Lisp Machine :)
Yep. The garbage collector was called "reboot".
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, 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" <······@genuity.net> wrote in message
······················@paloalto-snr1.gtei.net...
> In article <·············@grant.org>,
> Christopher C. Stacy <······@grant.org> wrote:
> >>>>>> On 21 Jun 2002 18:29:36 +0200, Julian Stecklina ("Julian") writes:
> >
> > Julian> Hello,
> > Julian> recently there was a debate about using some subset of Lisp to
write
> > Julian> a garbage collector aimed to be used afterwards in the
> > Julian> full language.
> >
> > Julian> I wondered whether a lisp dialect working without garbage
collection
> > Julian> already exists. From my experiences the GC is closely related to
the
> > Julian> way of programming. So my search seems fruitless. :)
> >
> >Earlier versions of the Lisp Machine :)
>
> Yep. The garbage collector was called "reboot".
And in today's world, that may still be an option for large datasets.
That SGI machine with 512 CPU's and 10TB of memory sounds like a fine system
that could make use of modern "reboot" technology, then you don't have to
worry about having a multi-cpu GC running. Doing a global GC on 10TB of heap
doesn't sound pleasant to me. (Even properly broken up, that's still 20 GB
per processor..*gulp*).
I know it's been proposed before that for some server operations, it may be
better to init the heap, fork(), Do Lot's O Work, and then rather than doing
a full Global GC, just (exit) and let the host process refork to "start
over". The trick there is knowing when the Global GC is about to hit, and,
of course, saving off any state. But for something fairly stateless like a
web server, why do a full GC?
Regards,
Will Hartung
(·····@msoft.com)
In article <··········@news5.nntpserver.com>,
Will Hartung <·····@msoft.com> wrote:
>
>"Barry Margolin" <······@genuity.net> wrote in message
>······················@paloalto-snr1.gtei.net...
>> Yep. The garbage collector was called "reboot".
>
>And in today's world, that may still be an option for large datasets.
Most modern Lisps have generational GC, so they rarely scavenge the entire
heap. The full GC is probably never necessary -- any data that lives that
long is probably part of the application's permanent data set that just
keeps growing. If it fills up, a full GC probably wouldn't recover much,
so it's probably time to restart the application from scratch.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, 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.
In article <·················@paloalto-snr1.gtei.net>, Barry Margolin
<······@genuity.net> writes:
>In article <··········@news5.nntpserver.com>,
>Will Hartung <·····@msoft.com> wrote:
>>
>>"Barry Margolin" <······@genuity.net> wrote in message
>>······················@paloalto-snr1.gtei.net...
>>> Yep. The garbage collector was called "reboot".
>>
>>And in today's world, that may still be an option for large datasets.
>
>Most modern Lisps have generational GC, so they rarely scavenge the entire
>heap. The full GC is probably never necessary -- any data that lives that
>long is probably part of the application's permanent data set that just
>keeps growing. If it fills up, a full GC probably wouldn't recover much,
>so it's probably time to restart the application from scratch.
Ick! That's the best argument I've heard for C in a while.
-- Attaining and helping others attain "Aha!" experiences, as satisfying as
attaining and helping others attain orgasms.
Dvd Avins wrote:
> >Most modern Lisps have generational GC, so they rarely scavenge the entire
> >heap. The full GC is probably never necessary -- any data that lives that
> >long is probably part of the application's permanent data set that just
> >keeps growing. If it fills up, a full GC probably wouldn't recover much,
> >so it's probably time to restart the application from scratch.
>
> Ick! That's the best argument I've heard for C in a while.
In the Lisp application I run, occasional full GCs are neither extremely
expensive nor useless.
Paul
········@aol.comNOSPAM (Dvd Avins) writes:
> In article <·················@paloalto-snr1.gtei.net>, Barry Margolin
> <······@genuity.net> writes:
>
> >In article <··········@news5.nntpserver.com>,
> >Will Hartung <·····@msoft.com> wrote:
> >>
> >>"Barry Margolin" <······@genuity.net> wrote in message
> >>······················@paloalto-snr1.gtei.net...
> >>> Yep. The garbage collector was called "reboot".
> >>
> >>And in today's world, that may still be an option for large datasets.
> >
> >Most modern Lisps have generational GC, so they rarely scavenge the entire
> >heap. The full GC is probably never necessary -- any data that lives that
> >long is probably part of the application's permanent data set that just
> >keeps growing. If it fills up, a full GC probably wouldn't recover much,
> >so it's probably time to restart the application from scratch.
>
> Ick! That's the best argument I've heard for C in a while.
Only if you don't consider what the C alternative is. If your server
application has a bunch of state that can't be collected, it either
needs it, or you forgot to drop your references to some of it. In C,
you'll either still need it, or you'll have not freed it, because you
still have references to it that you forgot to drop; OR you'll have
potential bugs, because you freed it anyway, OR you'll have no
references to it, and you were conservative, and didn't free it
because you weren't sure if there were still other referents. The
problem is really the proper construction of servers, which can be a
difficult problem. And very often, C servers solve it using the
reforking "GC" proposed above.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick:
? [server code gotchas]
? The
? problem is really the proper construction of servers, which can be a
? difficult problem. And very often, C servers solve it using the
? reforking "GC" proposed above.
actually, last time i checked, i could not find a single decent server
implementation in C with any sort of GC, not even RC but shockingly, one
very early version of bind had the early boehm collector it its tar file,
even though the code was not used. [presumably the author thought that
would be useful to him later on... :)]
oz
--
bang go the blobs. -- ponder stibbons
ozan s yigit <··@blue.cs.yorku.ca> writes:
> Thomas F. Burdick:
>
> ? [server code gotchas]
> ? The
> ? problem is really the proper construction of servers, which can be a
> ? difficult problem. And very often, C servers solve it using the
> ? reforking "GC" proposed above.
>
> actually, last time i checked, i could not find a single decent server
"a single decent source-available server". I know of proprietary
servers in C and C++ that have GCs.
> implementation in C with any sort of GC, not even RC but shockingly, one
> very early version of bind had the early boehm collector it its tar file,
> even though the code was not used. [presumably the author thought that
> would be useful to him later on... :)]
Uhm, if you count reforking as "GC" (with scare-quotes), then Apache
usually has a "GC", because most installations periodically refork to
fight memory leakage.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick:
? > actually, last time i checked, i could not find a single decent server
?
? "a single decent source-available server". I know of proprietary
? servers in C and C++ that have GCs.
fair correction. i know a number of them (earliest more than ten
years ago at a division of siemens/nixdorf) as well. too bad open
source hackers learn so very slowly...
oz
--
take the long short cut. -- animation rule of thumb (richard williams)
"Barry Margolin" <······@genuity.net> wrote in message
······················@paloalto-snr1.gtei.net...
| Most modern Lisps have generational GC, so they rarely scavenge the entire
| heap. The full GC is probably never necessary -- any data that lives that
| long is probably part of the application's permanent data set that just
| keeps growing.
So far so good.
| If it fills up, a full GC probably wouldn't recover much,
| so it's probably time to restart the application from scratch.
Rather, archive the data, because it may be needed (otherwise you wouldn't
call it the application's permanent dataset).
Archiving is easy though: save the image, then discontinue referencing the
old data. You will have with a set of overlapping archives, each covering
some specific period of time.
Robert
"Will Hartung" <·····@msoft.com> writes:
> And in today's world, that may still be an option for large datasets.
>
> That SGI machine with 512 CPU's and 10TB of memory sounds like a fine system
> that could make use of modern "reboot" technology, then you don't have to
> worry about having a multi-cpu GC running. Doing a global GC on 10TB of heap
> doesn't sound pleasant to me. (Even properly broken up, that's still 20 GB
> per processor..*gulp*).
Unless this dataset holds pointers to live objects it can be
effectively ignored by the garbage collector. Without knowing what
lives in that 20GB of data, one should not assume that a GC will
underperform managing that storage.
Will Hartung <·····@msoft.com> wrote:
+---------------
| "Barry Margolin" <······@genuity.net> wrote in message
| > Yep. The garbage collector was called "reboot".
|
| And in today's world, that may still be an option for large datasets.
|
| That SGI machine with 512 CPU's and 10TB of memory...
+---------------
Sorry, "only" 1 TB of main RAM, not 10. <URL:http://www.sgi.com/origin/3000/>
(You can put *exabytes* of disk on it, if you like, but that's
another story... <URL:http://www.sgi.com/products/storage/cxfs.html>)
+---------------
| ...sounds like a fine system that could make use of modern "reboot"
| technology, then you don't have to worry about having a multi-cpu GC
| running. Doing a global GC on 10TB of heap doesn't sound pleasant to me.
| (Even properly broken up, that's still 20 GB per processor..*gulp*).
+---------------
More like 2 GB per CPU (in large configs, 4 GB per CPU in small ones).
Happier now? ;-} ;-}
-Rob
-----
Rob Warnock, 30-3-510 <····@sgi.com>
SGI Network Engineering <http://www.rpw3.org/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
In article <·············@grant.org>,
Christopher C. Stacy <······@grant.org> wrote:
>>>>>> On 21 Jun 2002 18:29:36 +0200, Julian Stecklina ("Julian") writes:
>
> Julian> Hello,
> Julian> recently there was a debate about using some subset of Lisp to write
> Julian> a garbage collector aimed to be used afterwards in the
> Julian> full language.
>
> Julian> I wondered whether a lisp dialect working without garbage collection
> Julian> already exists. From my experiences the GC is closely related to the
> Julian> way of programming. So my search seems fruitless. :)
>
>Earlier versions of the Lisp Machine :)
And even once the GC was added, it was so slow and buggy that most users
didn't risk turning it on.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, 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.
In the mid 1980's, for some not very good reasons (in hindsight),
Inference Corp developed a CommonLisp variant which *allowed*, but did
not require, garbage-free programming. The only successful versions
worked atop another Lisp system, such as Symbolics Lisp, or Lucid Lisp.
There was still a garbage collector, but its use was minimized. The
internal code of the expert system tool for which this Lisp was
developed (called ART), was garbage-free (or intended to be so). User
Lisp code added to the system might or might not be garbage-free. The
code depended upon explicit freeing of data structures when they were no
longer needed, and all the associated crashes and bugs arising from
double-freeing. Users were not encouraged to use the garbage-free
programming constructs (I can't remember whether the documentation was
delivered to users or not) since their mistakes could crash the program
if they tried to use it. Rather, they were supposed to use the ART
language, which used the garbage-free constructs without exposing them
to the programmer. For the system developers, this brought some of the
worst nastinesses of C programming into the Lisp experience, although it
was still far better than C owing to the abstractions that could be used
in managing the memory.
Jeff
"Julian Stecklina" <··········@web.de> wrote in message
···················@blitz.comp.com...
> I wondered whether a lisp dialect working without garbage collection
> already exists. From my experiences the GC is closely related to the
> way of programming. So my search seems fruitless. :)
In article <··············@blitz.comp.com>,
Julian Stecklina <··········@web.de> wrote:
> recently there was a debate about using some subset of Lisp to write
> a garbage collector aimed to be used afterwards in the
> full language.
>
> I wondered whether a lisp dialect working without garbage collection
> already exists. From my experiences the GC is closely related to the
> way of programming. So my search seems fruitless. :)
Try searching for ThinLisp. (There used to be a ThinLisp.org, but I
can't connect to it right now.) I thought it was interesting when I saw
it announced (here in c.l.l., I believe), but I haven't used it yet. I
generate too much garbage.
From the README:
ThinLisp is an open source Lisp to C translator for delivering
commercial quality, Lisp-based applications. It implements a
subset of Common Lisp with extensions.
ThinLisp is not a typical Lisp implementation in that it does not
implement a garbage collector or many of the other run-time
development features of other Lisps.
* Dennis Marti <············@yahoo.com>:
> Try searching for ThinLisp. (There used to be a ThinLisp.org, but I can't
> connect to it right now.) [SNIP]
<URL:http://sourceforge.net/projects/thinlisp/>?
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
Julian Stecklina wrote:
>
> Hello,
>
> recently there was a debate about using some subset of Lisp to write
> a garbage collector aimed to be used afterwards in the
> full language.
>
> I wondered whether a lisp dialect working without garbage collection
> already exists. From my experiences the GC is closely related to the
> way of programming. So my search seems fruitless. :)
This might not be what you're looking for, but it /is/ a paper
on a different approach to garbage-free Lisp, and it is worth
reading --
http://linux.rice.edu/~rahul/hbaker/LinearLisp.html
> Julian
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
On 21 Jun 2002 18:29:36 +0200, Julian Stecklina <··········@web.de> wrote:
> I wondered whether a lisp dialect working without garbage collection
> already exists. From my experiences the GC is closely related to the
ThinLisp
http://thinlisp.sourceforge.net
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Hello!
In article <··············@blitz.comp.com>,
Julian Stecklina <··········@web.de> wrote:
>[... Lisp w/o GC ...]
Not a Lisp, but might be interesting to consider in a "oh, such a thing
exists, perhaps we could get ideas from it" way (or to use it albeit it
isn't Lisp, of course), is the ML Kit (http://www.it-c.dk/research/mlkit/).
It nowadays has a GC again, but version 3 IIRC relied only on
compile time region inference.
Kind regards,
Hannah.
* Hannah Schroeter
| Not a Lisp, but might be interesting to consider in a "oh, such a thing
| exists, perhaps we could get ideas from it" way (or to use it albeit it isn't
| Lisp, of course), is the ML Kit (http://www.it-c.dk/research/mlkit/).
|
| It nowadays has a GC again, but version 3 IIRC relied only on compile time
| region inference.
I think I may want some form of defaulting to dynamic-extent so that it does
exactly this, but the compiler will need to compute and propagate information
about the usage of incoming arguments in a function so that a caller can know
that no component of an argument was stored away elswhere. This is fairly
easy to prove for the whole function, but the meta-information required about
a function can easily lead to networks of information that lead to massive
recompilation upon simple changes, something we generally do not want, even
in fully incrementally compiled systems. Perhaps with lazy compilation like
you can do with some virtual-machine based systems, this would not be so bad,
but it is an "interesting" problem. Still, it would be very cool to use the
stack and its cheap de/allocation rather than the garbage collector for the
temporary data that only trigges garbage collection too often.
--
Guide to non-spammers: If you want to send me a business proposal, please be
specific and do not put "business proposal" in the Subject header. If it is
urgent, do not use the word "urgent". If you need an immediate answer, give
me a reason, do not shout "for your immediate attention". Thank you.