[gclist] Re: Linux and commercial compilers

[P. T. Withington]

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
>allocated.

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/>