Deprecations for 3.0
Vasily Chekalkin
bacek at bacek.com
Sat Sep 18 15:07:03 UTC 2010
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.
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.
--
Bacek
More information about the parrot-dev
mailing list