Deprecations for 3.0

[Nick Wellnhofer]

On 18/09/10 17:07, Vasily Chekalkin 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.

I'm talking about the PMC code here, not PIR. I mean all the assignments 
that are done with SET_ATTR macros, or directly in aggregate PMCs.

> 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.

So you propose to replace every vtable function that does an assignment 
to a PMC or STRING with a second version?

Nick