Newsgroups: comp.lang.dylan,comp.lang.lisp,comp.lang.java
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!delmarva.com!news-out.internetmci.com!internetMCI!newsfeed.internetmci.com!howland.reston.ans.net!ix.netcom.com!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: Garbage collection cost (was Re: Parenthesized syntax challenge)
Message-ID: <hbaker-2810950832030001@10.0.2.15>
Sender: hbaker@netcom16.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> <hbaker-2510951016220001@10.0.2.15> <46rkuv$jh8@news.parc.xerox.com>
Date: Sat, 28 Oct 1995 16:32:03 GMT
Lines: 63
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5685 comp.lang.lisp:19758 comp.lang.java:3061

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

> hbaker@netcom.com (Henry Baker) writes:
> 
> >The RISC 'revolution' has increased memory requirements for code by about
> >a factor of two.
> 
> My impression is that code density varies a lot between CISC processors,
> and that code density for "32 bit" code on an X86 is nothing to write
> home about either.  But RISC code is likely to be larger.

David Moon sent me a message indicating that the code blowup when going
from the 68K to the PowerPC (Apple Mac) was about 1.3X for C and 1.05X for
Dylan.  But he indicated that this factor was dependent on the optimization
settings for the compiler.

I haven't run tests on PowerPC compilers, but 80860 C compilers produced
code which was substantially less dense than that for the 80486 for
'usual' optimization settings.  I also didn't notice any great increase
in density when optimizing for density rather than speed.

> >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.
> 
> I don't know about Lisp implementations.  For C code, I don't believe
> this makes an appreciable difference.

On some RISC machines, asking for byte alignment blows code size size up
substantially.

> >I would advise using .-relative addressing for all pointers (perhaps some
> >C compiler vendor/GNU is listening), and start using VM compression.

> Please don't do that for C; you'll break conservative GC completely.
> (You'll also break at least all C code that calls third party libraries,
> and I doubt you'll have an ANSI conforming compiler.  How do you handle
> union assignments?  But I have my priorities straight :-))

I don't understand this.  There's nothing in C that guarantees that a pointer
points to an _absolute_ address; only that relative addresses work correctly.
In fact, many compilers optimize accesses in such a way that an absolute
pointer to an object may never be stored at all, since the object can be
easily reference relative to some nearby object.

Relative pointers should be less visible than the segmentation nonsense
(so NEAR and yet so FAR) of some brain-damaged processors.

> >Once you
> >have encoded pointers as _relative_ addresses instead of _absolute_
> >addresses, then VM compression will work better.

> Presumably the right place to convert to relative pointers is in the
> compressor?

In current architectures, the answer is probably yes.  Some sort of
'pointer-swizzling' or equivalent could do this.

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