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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
