On Sat, Sep 18, 2010 at 11:07 AM, Vasily Chekalkin <[email protected]> wrote: > On Sat, Sep 18, 2010 at 11:20 PM, Nick Wellnhofer <[email protected]> wrote: >> On 18/09/10 06:06, Luben Karavelov wrote: >>> >>> The idea is that we could dynamically swap vtables of objects that >>> should be >>> barriered. The new vtable will contain functions that execute >>> barrier-ing >>> logic (card marking, scavenging etc.) and re-dispatch to the original >>> vtable >>> function. >> >> That simply doesn't work. It's not enough to run a bit of code before every >> vtable function. We have to check every PMC assignment in every vtable >> function and all the functions it calls. There's no way around that. Note >> that it's completely different in a purely functional language without >> assignment like Haskell. > > 1. It does. All "assignments" are actually vtable calls. E.g. > VTABLE_set_integer_native, etc.
This conflicts with things playing games and assigning directly into PMCs as is done now by MMD and PCC. Not that this is necessarily a bad thing. > 2. We are not going to "run bit of code before every vtable call". > "Write barrier" vtable will just invoke something like > interp->gc_subsystem->write_barrier(SELF), replace SELF->vtable with > non-protected one and then redispatch call to normal vtable method. > 3. When "GC" will move object into older generation it will just > replace PObj->vtable with "write barrier" version. > > There is still some caveats with METHODs, but they can be solved in > similar manner. If I've understood correctly, this is a bit of a shotgun approach. Any PMC that could get referenced by SELF is assumed to be referenced. Any old PMC that could reference a dirty PMC must become dirty (because it could traverse the graph and assign a young PMC into itself). In fact, any PMC that references a PMC that has become dirty must itself be marked dirty (because it could traverse the now-dirty PMC in any vtable). The set of dirty PMCs could grow quite quickly. In practice, this may not occur that much, but the approach does have downsides. Overall, the approach sounds complicated with the potential for hard to track bugs. Given our rate of progress on GC, wouldn't it be wise to do something easier but less awesome first? And if it turns out we don't need the macros because we've got this other approach up and running, great; otherwise, we have something to fall back upon. > -- > Bacek > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
