Deprecations for 3.0
Vasily Chekalkin
bacek at bacek.com
Sat Sep 18 22:07:13 UTC 2010
Hello.
On Sun, Sep 19, 2010 at 7:41 AM, Luben Karavelov <karavelov at spnet.net> wrote:
> On Sat, 18 Sep 2010 19:09:26 +0200, Nick Wellnhofer
> <wellnhofer at aevum.de> wrote:
>>
>> So you propose to replace every vtable function that does an
>> assignment to a PMC or STRING with a second version?
>>
>
> 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.
It's up to GC implementation to decide how to handle dirty objects
from old generations. Simplest idea - put dirty object to rootset for
next collection. During mark phase (if we marking young generation
only) we will skip referenced object from old generations.
> - there are places (not in PMCs) that manually change PMC
> attributes, not through vtable calls.
Direct poking into attributes was made for performance reasons. We
have to put explicit "write barriers" in front of it.
--
Bacek
More information about the parrot-dev
mailing list