[gclist] Finalizers & Reference counting.

[Nick Barnes]

At 2002-08-28 21:00:03+0000, Manoj Plakal writes:
> FYI, you can read the message and
> follow the thread starting here:
>   http://gcc.gnu.org/ml/gcc/2002-08/msg00544.html

As far as I can tell, nobody in this thread was able to produce real
numbers on cache performance of GCC on x86 (despite the existence of
CPU performance counters and tools to use them, which should allow
that).  Someone produced numbers for GCC on AIX/Power4, which weren't
great but which weren't appalling either:

<http://gcc.gnu.org/ml/gcc/2002-08/msg00763.html>

Maybe the most interesting message in the thread was one in which
Torvalds gives the following interesting reason to dislike GC (while
confirming, subsequently in the same message, that he is prejudiced
against GC).  <http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html>:

    One fundamental fact on modern hardware is that data cache
    locality is good, and not being in the cache sucks.  This is not
    likely to change.  In particular, this means that if you allocate
    stuff, you want to re-use the stuff you just freed
    _as_soon_as_possible_ - preferably before the previously dirty
    data has ever even been evicted from the cache, so that you can
    re-use the thing to avoid reading it in, but also to avoid writing
    out stale data.
    
    This implies that any lazy de-allocation is bad. When a piece of
    memory is free, you want to de-allocate it _immediately_, so that
    the next allocation gets to re-use it and gets the cache footprint
    "for free".

Nick B