Deprecations for 3.0

[Peter Lobsinger]

On Sat, Sep 18, 2010 at 11:07 AM, Vasily Chekalkin <bacek at bacek.com> wrote:
> On Sat, Sep 18, 2010 at 11:20 PM, Nick Wellnhofer <wellnhofer at aevum.de> 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
>