Newsgroups: comp.lang.dylan,comp.lang.lisp,comp.lang.java
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!swrinde!tank.news.pipex.net!pipex!news.mathworks.com!newsfeed.internetmci.com!news.sprintlink.net!noc.netcom.net!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: Garbage collection cost (was Re: Parenthesized syntax challenge)
Message-ID: <hbaker-2510951016220001@10.0.2.15>
Sender: hbaker@netcom7.netcom.com
Organization: nil organization
References: <44aa9a$j5h@miso.cs.uq.edu.au> <LUDEMANN.95Oct6140930@expernet26.expernet.com> <DGApp8.J41@undergrad.math.uwaterloo.ca> <MAD.95Oct13123618@tanzanite.math.keio.ac.jp> <45ksdk$7gr@jive.cs.utexas.edu> <DGJp8o.7nF@Cadence.COM> <MAD.95Oct18040436@tanzanite.math.keio.ac.jp> <hbaker-1710952127200001@10.0.2.15> <46jb8v$sm8@news.parc.xerox.com>
Date: Wed, 25 Oct 1995 18:16:22 GMT
Lines: 37
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5594 comp.lang.lisp:19700 comp.lang.java:2675

In article <46jb8v$sm8@news.parc.xerox.com>, boehm@parc.xerox.com (Hans
Boehm) wrote:

> 2. As a result, I claim the average PC is grossly underconfigured with
> memory.  Most PCs would gain much more from a memory upgrade than a
> processor upgrade, if they're running anything beyond DOS.  RISC
                                                              ^^^^
> workstations tend to be configured a bit more reasonably, but users
> expect something in return for the extra money they paid for
> memory.

The RISC 'revolution' has increased memory requirements for code by about
a factor of two.

Furthermore, due to RISC requirements for data alignment, RISC _data_ has
also gotten much less dense -- e.g., I'm not aware of any RISC Lisps which
do 'cdr-coding' anymore.  I would imagine that the RISC revolution has
expanded data requirements by perhaps 1.5X.

Therefore, unless you start using some form of VM
compression on code pages, you are probably in worse shape than before
RISC, because you are going to page fault more often than a CISC architecture
with the same amount of memory, and this is a very non-linear phenomenon.
(RISC processors should be very good at doing compression, so the overall
cost of this should be quite small.)

I would advise using .-relative addressing for all pointers (perhaps some
C compiler vendor/GNU is listening), and start using VM compression.  Once you
have encoded pointers as _relative_ addresses instead of _absolute_
addresses, then VM compression will work better.

I think that these techniques will pay off much better as a first
priority than playing around with GC cons/mark ratios.

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
