Deprecations for 3.0

[Nick Wellnhofer]

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

Nick