Newsgroups: comp.arch,comp.lang.scheme,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!uknet!dcs.gla.ac.uk!bos
From: bos@dcs.gla.ac.uk (Bryan O'Sullivan)
Subject: Re: Validating/using all 2^lgn address bits
Message-ID: <Cvntov.9B1@dcs.gla.ac.uk>
Organization: Umbrella, cheese, turn right, louder music, leaf mould
References: <33um9uINNs6h@usenet.pa.dec.com> <341c2aINNh1l@usenet.pa.dec.com> <jthillCvFG72.1w9@netcom.com> <345h8a$98d@peaches.cs.utexas.edu> <CvI4vJ.70v@apollo.hp.com>
Date: Mon, 5 Sep 1994 14:02:55 GMT
Lines: 43
Xref: glinda.oz.cs.cmu.edu comp.arch:52777 comp.lang.scheme:9699 comp.lang.lisp:14465

sommerfeld@apollo.hp.com (Bill Sommerfeld) writes:

>With respect to using a subfield of the address as a type tag: given a
>sufficiently large sparse address space, you can "just do it" by
>allocating different primitive types in different parts of the address
>space.

This has been done for quite a long time, even on machines with fairly
small address spaces.  The allocation technique is known as BIBOP, for
``Big Bag O' Pages'', and seems to have mostly died out (due in part to
the historical lack of support in Unix for attaching memory to random
chunks of address space).

In general, it seems that systems which use BIBOP like to have a `real'
type tag associated with heap objects as well as a high-bit type.  This
is because 32-bit address spaces don't give you enough high address
bits to play freely with, so you reserve smallish sets of pages for
allocating objects of each type.  Using a pure BIBOP system, you then
have to do a little bit of table lookup before you can determine what
type an object is from its high address bits.

The only current Lispy implementation I know of that uses BIBOP typing
is Chez Scheme from Indiana University (see IU TR 400), which uses it
solely for the storage manager to play with; run-time type
identification for other purposes is done using normal tag bits, being
faster as outlined above.  The claimed win is that BIBOP frobbery makes
it easier for Chez' allocator and collector to accommodate other
languages' run time systems -- the GC can sweep through memory in the
normal fashion, but when it reaches a group of pages marked as
`externally allocated', it just skips past them.  There's also some
cleverness in their BIBOP system that allows their generational GC to
avoid copying large objects, though I can't remember the exact details
of this.

I don't know what the Chez folks make of the possibilities of thrashing
the TLB or cacking on access locality as mentioned by Rob MacLachlan.

	<b

-- 
Bryan O'Sullivan               u nas est tolko odyeen yagnyonok seychas.
Inadequate Pay Department      email: bos@cyclic.com,  bos@dcs.gla.ac.uk
University of Glasgow          web.gunge: http://www.scrg.cs.tcd.ie/~bos
