Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 12:04 AM -0500 1/20/04, Gordon Henriksen wrote: >>C was not marked reachable (although it was) and was thus >>erroneously collected, leaving a dangling pointer. This problem >>applies equally to copying and mark-sweep collectors.
> Ah, OK, I see. That is well knowm in the literature as "Tri-Color Invariant": Black are the already marked (live) PMCs, grey the PMCs on the next_for_GC list, white the not yet reached PMCs. The strong tri-color invariants states that no black object may point to a white object, the weak invariant states, that at least one path from the black to a white object must contain a grey one. This can be handled by either stop the world GCs or by intercepting each read or write access that would change the color of an object and update the color accordingly. This is e.g. used for incremental GC. As soon as we have a thread in the background that runs GC, we have to cope with these issues. > That means we're going to have to have either a really forgiving DOD > system that takes multiple passes before it collects up a PMC or > buffer (which still isn't safe) Alas not an alternative, it doesn't work. > ... or have some way to force a > low-overhead rendezvous. > Okay, we're going to mandate that we have read/write locks, each > interpreter pool has one, and mutating vtable entries must get a read > lock on the pool read/write lock. Pricey (ick) but isolated to > mutators. The DOD gets a write lock on it, which'll block all > read/write access so no mutators can be in process while the pool DOD > runs. Stopping all interpreters seems to be cheaper. The rwlock will sooner or later stop all interpreters anyway (on first PMC access), so we can omit the price for the rwlock and just hold the world(s). An alternative would be real background incremental GC, *when* running multiple threads. I estimate the overhead to be in regions of a rwlock (with no contention of course). leo
