On Jan-13, Jason Gloudon wrote: > On Fri, Jan 10, 2003 at 01:05:05PM +0100, Leopold Toetsch wrote: > > > >While I'd like no stack walking, as it's pricey, I'm not sure it's > > >tenable. > > > > As the current clone changes does show, it's possible. > > > > BTW current tests do succed w/o stackwalking - its disabled. > > > > >... Skipping it makes things rather more fragile, as it means that > > >any code that may potentially trigger a DOD run while holding an > > >unrooted object needs to root it temporarily, and that's a lot of code. > > Without the stack/register examination the following can occur (though nothing > does this yet) > > 1) A PMC is accessible from the root set when a vtable is called. Either via a > reference or being a member of an aggregate. > > 2) A vtable function obtains a PMC* to that PMC. > > 3) The vtable calls some code deletes the reference to the PMC, which is now > no longer accessible from the root set. The vtable then attempts to allocate > some memory.
Nope, that example is just a plain ol' use-of-freed-memory bug. If you delete something, don't look at it again. However, if you change the example to simply unanchoring the PMC, then you have a problem. For example, consider a vtable method that is removing a PMC from the middle of one aggregate and pushing it onto the end of another. If you remove the PMC first (replacing it with an undef PMC, say) and then push it onto the second aggregate, the push operation may allocate memory (to expand the aggregate) at a time when the PMC is unanchored. This is similar to the infant mortality, but shows that it doesn't only happen to infants. The solution is also similar: reorder instructions. If you push the PMC onto the second aggregate before removing it from the first, you're ok. And once again, it's unclear how big of a restriction this is in general, and in particular for extension code. (Although I'd probably deal with extensions by disabling DOD for them by default, but providing a flag bit they can set that says "in return for keeping the garbage collector active while I run, I promise to follow all the necessary rules.") Re: incremental gc It seems to me that the nice way of getting incremental gc would be to only provide it on platforms that provide the necessary hardware support. Then, rather than making the other platforms slower, have them use a non-incremental collector. (Actually, we'd probably want the option of not using the incremental collector even on the platforms that support it, since it would most likely be trading throughput for latency.) The trick is that the restrictions on extension code would then need to be the union of the restrictions for all the different gcs -- so those sets of restrictions had better be very similar!
