[gclist] Re: Linux and commercial compilers

[Hans Boehm]

On Nov 5,  5:30pm, Malcolm Cohen wrote:
> Anyway, to get back to gc: NAGWare Fortran comes with the Boehm et al
> collector.  This seems to satisfy most of that subset of the Fortran
> community that want gc; only the lack of performance when large (10MB+?)
> objects are being allocated seems to be a real problem (it seems to go
> into an infinite loop allocating memory from the O/S - at a guess, trying
> to find a spot that is not black-listed, though I could be wrong about that;
> has anyone else had more success here?  is it a Linux problem?).
>
There are actually three issues here, two of which are important:

1) Garbage collecting allocators aren't good at very large objects.  Period.
 That's one place were explicit deallocation (or maybe substantial hints from
the client) win.  The fundamental problem is that allocating a large object
with a GC brings you much closer to the next GC.  It has to.  You can't
generally afford to let the client allocate lots of large objects in a row
without collecting.  Effectively, allocation cost in a GC environment is
proportional to the size of the object.  With malloc/free, it's essentially
constant.  (Initialization will eliminate the asymptotic difference.  But costs
still differ by a very significant constant.)  In many environments it makes
sense to manage large objects explicitly even if small objects are garbage
collected.  Fortunately that's often also very easy to do.

2) Conservative garbage collectors that recognize interior pointers are even
worse at large objects, as you point out.  It's very difficult to find a 10 MB
chunk that won't have a pointer to somewher in the middle.  My collector has a
hook to tell it not to recognize interior pointers to such objects (which
requires that you keep a pointer to near the beginning).  Something like the
NAG compiler would either have to take advantage of that hook automatically or
make it visible to the user.

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.  I don't know of any Linux-specific problems in this area.

Hans



-- 
Hans-Juergen Boehm
boehm@mti.sgi.com