There is something I'm intensely curious about as I learn lisp. In
Graham's "Inside Orbitz" article, an Orbitz employee mentions, "Lisp
garbage collectors just can't deal with gigs of data, and there's no
way to rapidly load gigs of data into a Lisp." However, I've read
that Lisp runs quite well on hardware designed for it. On alternate
hardware where lisp is an assembly language, would this garbage
collection problem still be a problem?
Also, it seems at least conceivable that one can purposefully
deallocate objects in lispish syntax, rather than let the gc take care
of it. Did lisp machines offer this as an option, perhaps in some
special mode where you can access low level commands?
Tayss wrote:
> There is something I'm intensely curious about as I learn lisp. In
> Graham's "Inside Orbitz" article, an Orbitz employee mentions, "Lisp
> garbage collectors just can't deal with gigs of data, and there's no
> way to rapidly load gigs of data into a Lisp." However, I've read
> that Lisp runs quite well on hardware designed for it. On alternate
> hardware where lisp is an assembly language, would this garbage
> collection problem still be a problem?
I have heard from inside sources that the issue is not GC, but the fact that
the images are so large that they run out of address space on stock
hardware. Most Lisps use at least one or two bits of each register for
type tags, and so are limited to 1-2 GB memory spaces. They literally have
no additional space available for GC. This would still be an issue on any
of the old LispM's out there (built in days of small memories, they only
had a few M of physical memory and so would page GB images to death).
The Orbitz folk probably don't like coding within these memory restrictions
any more than we would like to. They (like many of us) are waiting for a
64-bit system to appear. Even at that, simply because of the size and
run-times of their systems, I doubt that relying on GC would be
appropriate, as they already need every CPU cycle available to run their
system - they code their core algorithms in a VERY efficient (and not very
programmer friendly) style, avoid consing at all costs, etc.
In many ways, the Orbitz application is atypical. Trying to define Lisp
capabilities based on their needs is probably overkill.
Frank A. Adrian wrote:
> ... Most Lisps use at least one or two bits of each register for
> type tags, and so are limited to 1-2 GB memory spaces. They literally have
> no additional space available for GC.
Whatever limitation there may be on the needs of a garbage collector to
manage large amounts of memory, it has nothing to do with tag bits.
Hardware generally likes to have objects allocated on 8-byte boundaries
(or sometimes 4) which allows 3 tag bits to be located in the _low_ order
bits of a pointer. They create no limitation on pointers to reference the
entire 32-bit address space, or at least as much of it as the OS is willing
to map.
In article <····························@posting.google.com>,
Tayss <··········@yahoo.com> wrote:
>There is something I'm intensely curious about as I learn lisp. In
>Graham's "Inside Orbitz" article, an Orbitz employee mentions, "Lisp
>garbage collectors just can't deal with gigs of data, and there's no
>way to rapidly load gigs of data into a Lisp." However, I've read
>that Lisp runs quite well on hardware designed for it. On alternate
>hardware where lisp is an assembly language, would this garbage
>collection problem still be a problem?
Many Lisp implementations provide ways to tune the GC. For instance, Lisp
Machines allow you to specify different GC parameters (including no GC) for
different regions of memory. An application that works with gigs of static
data would create a non-GCed region and load it into that area.
>Also, it seems at least conceivable that one can purposefully
>deallocate objects in lispish syntax, rather than let the gc take care
>of it. Did lisp machines offer this as an option, perhaps in some
>special mode where you can access low level commands?
There's nothing stopping an application from calling the internal functions
that the GC itself uses, but I can't recall anyone ever doing that.
Applications that wanted to handle their own memory management often used a
facility called "resources". These managed a pool of similar data objects,
and provided functions to retrieve them from the pool and then return them
for later use. This was most often used for objects that were used very
briefly and needed frequently, like network buffers.
--
Barry Margolin, ··············@level3.com
Level(3), 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 <··············@level3.com> wrote in message news:<·················@news.level3.com>...
> There's nothing stopping an application from calling the internal functions
> that the GC itself uses, but I can't recall anyone ever doing that.
>
> Applications that wanted to handle their own memory management often used a
> facility called "resources".
Ok, so this seems to also explain how one would write realtime apps on
these LispM's, if one didn't trust or want to depend on a realtime gc.
Does anyone know where I could find good LispM documentation? Rainer
Joswig links to someone on spies.com, but that page is gone. And the
Symbolics Museum turns up nada. Hardcopy would be cool if it's not
expensive. I don't think I'll find anything at the uni library here
in Cologne...
In article <····························@posting.google.com>,
··········@yahoo.com (Tayss) wrote:
> Barry Margolin <··············@level3.com> wrote in message
> news:<·················@news.level3.com>...
> > There's nothing stopping an application from calling the internal functions
> > that the GC itself uses, but I can't recall anyone ever doing that.
> >
> > Applications that wanted to handle their own memory management often used a
> > facility called "resources".
>
> Ok, so this seems to also explain how one would write realtime apps on
> these LispM's, if one didn't trust or want to depend on a realtime gc.
>
> Does anyone know where I could find good LispM documentation? Rainer
> Joswig links to someone on spies.com, but that page is gone.
The documentation seems to be available - atleast for me.
I just looked at that site and it is online.
http://www.spies.com/~aek/pdf/symbolics/
http://www.spies.com/~aek/pdf/ti/explorer/
http://www.spies.com/~aek/pdf/mit/
http://www.spies.com/~aek/pdf/mit/cadr/chineualJan84/
http://www.spies.com/~aek/pdf/xerox/interlisp/
> And the
> Symbolics Museum turns up nada. Hardcopy would be cool if it's not
> expensive. I don't think I'll find anything at the uni library here
> in Cologne...
Rainer Joswig <······@lispmachine.de> wrote in message news:<····························@news.fu-berlin.de>...
> The documentation seems to be available - atleast for me.
> I just looked at that site and it is online.
Wonderful! I should have been more patient.