[gclist] Re: Linux and commercial compilers

P. T. Withington ptw@harlequin.com
Wed, 5 Nov 1997 15:11:44 -0500

At 13:59 -0600 11/5/97, David Gadbois wrote:
>   From: boehm@hoh.mti.sgi.com (Hans Boehm)
>   Date: Wed, 5 Nov 1997 10:38:07 -0800
>   [...]
>   1) Garbage collecting allocators aren't good at very large objects.
>There are some tricks you can play to make big objects not be such a
>big deal.  With a generational collector, instead of copying large
>objects, you can just tweak the bookkeeping information so that it
>indicates that the object is in an older, target generation.  You
>still have to scavenge the big object, but at least no new memory is

And often big objects are devoid of references, e.g., they might be
bitmaps, arrays of floats, etc.  Allocating such objects in a way that the
GC knows it never needs to scan them can also be a big win.  A hint from
the compiler is best (lest the programmer lie).

>   [...]
>   3) (Less profound) It took a few iterations to get the black list
>   interactions with large objects right in my collector.  I suspect
>   NAG is using a version that still has problems in this area.  More
>   recent versions should succeed at allocating the 10 MB, but will by
>   default usually give you warning, and may fail to reclaim it.
>Is there any data on what kind of benefit blacklists give?  For the
>kinds of workloads I run under a non-blacklisting conservative
>collector, I don't see how they would be worth the hassle.  This is in
>the sense that the working set size seems to be accounted for purely
>in terms of allocation.  How does one measure blacklisting benefits at
>a finer granularity?
>   I don't know of any Linux-specific problems in this area.
>Well, one of the annoying things is that there is no APIish way of
>figuring out what portions of the address space have been allocated.
>Either you have to poke around and catch SIGSEGVs or else parse the
>contents of /proc/nnn/maps.  And you get into races if someone else is
>trying to fiddle with the address space at the same time.

A good reason that GC ought to be built-in to the O/S.

P. Tucker Withington, Harlequin Inc., One Cambridge Center, Cambridge MA 02142
Phone: +1 617 374 2557       Fax: +1 617 252 6505      "Honk if you love GC's"
The Memory Management Reference:  <URL:http://www.harlequin.com/mm/reference/>