Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.mathworks.com!news.kei.com!nntp.coast.net!col.hp.com!news.dtc.hp.com!hplntx!hplntx.hpl.hp.com!gjr
From: gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas)
Subject: Re: Schemes that allow *large* heap/stack?
Sender: news@hpl.hp.com (HPLabs Usenet Login)
Message-ID: <GJR.96Mar29094520@hplgr2.hpl.hp.com>
In-Reply-To: kdj@aimnet.com's message of 28 Mar 1996 16:15:15 -0800
Date: Fri, 29 Mar 1996 17:45:20 GMT
Reply-To: gjr@hpl.hp.com
References: <4jfa2j$q0f@aimnet.aimnet.com>
Nntp-Posting-Host: hplgr2.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Palo Alto, CA
Lines: 58

In article <4jfa2j$q0f@aimnet.aimnet.com> kdj@aimnet.com (Kevin Jones) writes:

|   From: kdj@aimnet.com (Kevin Jones)
|   Newsgroups: comp.lang.scheme
|   Date: 28 Mar 1996 16:15:15 -0800
|   Organization: Aimnet Corp.
|   Lines: 29
|   NNTP-Posting-Host: aimnet.aimnet.com
|
|   We use scheme as the implementation language for a verification
|   tool. One of the wonderful things about test vectors is that you can
|   never have enough of them, so we really need to use large amounts of
|   memory when generating big regression tests.
|
|   It seems that scheme is the biggest limiting factor in our world at
|   the moment. We use MIT scheme 7.3, and even using the bchscheme
|   variant of this, it seems that the biggest image space we can get on a
|   HP 7000 is -heap 1200 -stack 3n000, and this is on machines with either
|   128 or 256 Meg of real memory with up to a Gig of VM. It doesn't seem
|   like doubling either the physical or virtual memory makes any
|   difference to scheme.
|
|   It seems that this implementation of scheme is limited by factors
|   other than either of the obvious memory limits. Unless I'm missing
|   something, that is?

MIT Scheme uses the high 6 bits of a word for a type tag.  It is a
legacy of its origin as a simulator for the Scheme-81 chip, which used
such a tagging scheme.

The high tagging is a cause of non-negligible performance loss on
modern machines (especially since most lack fast bit-field insert and
extract instructions, something that PA RISC fortunately has), and,
more relevant to your case, the loss of addressibility on 32-bit
computers.

MIT Scheme on 32-bit computers can address at most (2^(32-6)) = 64 Mbytes.

On 64-bit computers it can address 2^(64-6) bytes, although I believe
that the Alpha port actually used a whole byte for the type tag.

Reducing the number of tag bits would be a very painful operation
given that most of the runtime system depends on a large number of
"low level" types being available.  It has been considered in the
past, but no one has bothered to.

One last comment about MIT Scheme.  Its garbage collector is a rather
simple variant of the Minsky,Fenichel,Yokelson (spelling?) collector.
In particular, it is not generational.  Many people have found this to
be a problem when dealing with truly large images.

|   Can anyone point me at a full implementation of scheme that allows
|   really large images?

I would also advise you to look for a generational GC in the
implementation that you choose.  I believe that Chez Scheme has one
and is not similarly hampered.  However, I do not know if it runs on
PA-RISC.
