[Gc] Re: [PATCH] Dealing with `.data.rel.ro'

Boehm, Hans hans.boehm at hp.com
Wed Sep 2 11:05:06 PDT 2009

> From:  Ludovic Courtès
> Hello,
> "Boehm, Hans" <hans.boehm at hp.com> writes:
> > I checked in the last .data.rel.ro patch with Ivan's corrections, 
> > derived from Ludo's patch.
> >
> > I suspect this may sometimes result in appreciable improvements in 
> > speed or space on Linux.
> I finally got around to measuring that on Guile/libgc:
>   https://thread.gmane.org/gmane.lisp.guile.devel/9247
> There's a noticeable improvement for Guile.
> However, the surprising part of the results is that static 
> allocation of some of Guile's objects known at compile-time 
> ("bdw-gc-static-alloc") when *not* linking with `-z relro' 
> leads to a slight execution time degradation and increased 
> heap usage---whereas we'd really expect heap usage to be 
> reduced since some objects are statically allocated instead 
> of being allocated on the heap when Guile is started.
> How would you explain this?
> Thanks,
> Ludo'.

If I understand correctly, this may not be too surprising.  At least it makes sense that it doesn't help.

The basic issue may be that some of the heap objects would have been pointer-free, but they're traced when they're allocated statically.

The reason that this may adversely affect the heap size is a bit more complicated.
The collector tries to spend roughly a constant amount of time per heap allocation.  It does so by sizing the heap so that for every byte traced, it gets to allocate x bytes(usually a fraction) during a GC cycle.  The number of bytes it expects to trace is calculated in min_bytes_allocd().  It includes the number of root bytes, though they're weighted only half as much as pointer-containing memory in the heap.  But root bytes are weighted more than pointer-free memory in the heap, since the latter isn't really traced.  Thus if you're moving pointer-free objects to static regions, the GC may correctly decide that it needs a bigger heap to amortize the additional tracing time.

I don't know the extent to which you're actually using pointer-free (atomic) objects, so this may be off-base ...


More information about the Gc mailing list