[gclist] Re: Linux and commercial compilers

[David Gadbois]

   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.

   [...]

   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.

--David Gadbois