Garbage collection and optimization

Rayiner Hashem <>
Mon, 05 Nov 2007 21:01:48 -0000

          From comp.compilers

Related articles
Garbage collection and optimization (Rayiner Hashem) (2007-11-05)
Re: Garbage collection and optimization (Paolo Bonzini) (2007-11-08)
| List of all articles for this month |

From: Rayiner Hashem <>
Newsgroups: comp.compilers
Date: Mon, 05 Nov 2007 21:01:48 -0000
Organization: Compilers Central
Keywords: GC, question
Posted-Date: 06 Nov 2007 10:41:27 EST

How do GCs with thread-local, unsynchronized, bump-pointer style
allocation (eg: Sun's JVM and its TLABs), interact with code
optimizers? Specifically, how do they handle the case where one thread
is in the middle of constructing an object when another thread cases a
collection to start? The object may be in an inconsistent state, so
the GC can't scan it, but it also may contain the last remaining
pointers to some objects that need to be kept alive. Consider the
following structure:

typedef struct _cons {
    struct _cons* car;
    struct _cons* cdr;
} cons;

The allocation routine might look like:

cons* alloc_cons(cons* car, cons* cdr) {
    if((alloc_ptr + sizeof(cons)) > alloc_limit)

    cons* obj = (cons*)alloc_ptr;
    obj->car = car; /* one */
    obj->cdr = cdr; /* two */

    alloc_ptr += sizeof(cons); /* three */

    return obj;

If the GC interrupts before 'one' or after 'three', we're fine. 'car'
and 'cons' will remain live since their values will be used later.
However, what happens when the GC interrupts between 'one' and 'two'?
The GC won't see an incomplete object, since the allocation pointer
hasn't been bumped yet, which is fine, but it also won't trace through
'obj->car'. If the GC is semi-conservative and 'car' is still in a
register, then we can count on the fact that 'obj->car' will remain
valid after the allocation (the object won't have moved), but since
'car' is technically dead at that point, we have no guarantees, right?

What solutions to this problem are used in practice?

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.