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. :)
>>>>> 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. :)
In article <ulm981kf1....@grant.org>, Christopher C. Stacy <cst...@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, bar...@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" <der_jul...@web.de> wrote in message
> 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. :)
> >>>>> 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 <ja...@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 <ulm981kf1....@grant.org>, Christopher C. Stacy <cst...@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, bar...@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 <ulm981kf1....@grant.org>, > Christopher C. Stacy <cst...@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?
>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, bar...@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.
>>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.
In article <87adpoh9xr....@blitz.comp.com>, Julian Stecklina <der_jul...@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.
| 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.
"Will Hartung" <wi...@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.
> 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 --
-- 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.
> >>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! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
? [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... :)]
> ? [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! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
? > 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)
In article <87adpoh9xr....@blitz.comp.com>, Julian Stecklina <der_jul...@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.
* 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.
+--------------- | "Barry Margolin" <bar...@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... +---------------
+--------------- | ...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 <r...@sgi.com> SGI Network Engineering <http://www.rpw3.org/> 1600 Amphitheatre Pkwy. Phone: 650-933-1673 Mountain View, CA 94043 PP-ASEL-IA
[Note: aaanal...@sgi.com and zedwa...@sgi.com aren't for humans ]
