Deprecations for 3.0
wellnhofer at aevum.de
Sun Sep 19 12:58:43 UTC 2010
On 18/09/10 23:41, Luben Karavelov wrote:
> Yes, that's the idea. For generational GC we replace original
> vtable with the modified vtable when we move an object from
> new to old generation. In the new vtable we install trampoline
> functions only on vtable slots that could change a pointer (PMC
> or STRING) that mark the object as dirty then it passes control
> to the original function.
> Everything plobsing said about downsides of this approach is
> - we will mark as dirty all modified object in the old
> generation, not only those that install pointer to new
> generation objects - so the dirty object list will be
> not so precise.
> - there are places (not in PMCs) that manually change PMC
> attributes, not through vtable calls.
> It's an option to consider
OK, now I understand. It's definitely an interesting approach.
But for most other solutions we will need an explicit write barrier like
the macros I proposed. I still think it's a good idea to start to use
those macros, so we can experiment with other ideas.
More information about the parrot-dev