Ted Lemon
Posts: 4
Nickname: abhayakara
Registered: Dec, 2010
|
|
Re: Azul's Pauseless Garbage Collector
|
Posted: Dec 22, 2010 7:07 AM
|
|
Nono. Consider the case of a simple stop-and-copy collector. At any given time, all of the objects are in a single arena. When you hit the high water mark, you stop consing and allocate a new, bigger arena. You then iterate across all the root pointers in your system, copying every object reached by the root pointers into the new arena. Whenever you copy an object, you leave a fixup object in its place; this object has the address of the moved object. When you are scanning the roots, whenever you come to a pointer to a fixup object, you fix it and stop scanning, knowing that every object reached through the fixed-up object has already been reached. Once you have explored all the roots, all reachable objects will have been copied into the new arena, and you can just discard the old arena, knowing that any objects not reached are garbage.
So for example suppose you have an object A, which references object B. And you have another object, C, which references B as well. And suppose both A and C are reached by different roots. When you go to collect, you will reach A, and A will point to B in the old arena. So you'll move A into the new arena, and then move B into the new arena, and then adjust A's pointer to B. And you will update the version of B in the old arena to be a fixup object. Later on in the collection pass when you reach C, C's pointer to B will be pointing to the fixup object in the old arena. So you will copy C into the new arena, and update C's pointer to B using the information in the fixup object.
Now in this read-barrier model, suppose you move A and B, and fix up A's reference to B. And now suppose that your program accesses C after you've moved A and B. C's pointer to B will be pointing into the old arena, which has a read barrier, so you'll get a trap at that point, and you'll have the old address of B in the trap exception data. But what you won't have in the exception data is the address of C. And you need the address of C in order to update C's pointer to B.
So my original question was not how you got the address of B, but how you got the address of C. The only way I can think of to do it is to use your knowledge of the JVM--perhaps you know that when B is referenced, the object that referenced B must be in some register. If that's how they're doing it, then this isn't a general mechanism--it will only work with a specific JVM.
Hm, so are you saying that you take the fault when you reference C, which is in the old arena, not when you reference B? In that case, the fault address would be the address of C, and you'd be able to move C and update C's pointers at that time. If that's the case, then I've been missing what's novel about this approach, because using a read barrier in this way has been done before.
|
|
Previous Topic
