Garbage collection and optimization

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)
        make_more_space();


    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?

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