Deprecations for 3.0

Nick Wellnhofer wellnhofer at
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
> 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.


More information about the parrot-dev mailing list