Re: Patches that will come...

On 2 Sep 2004, at 10:54, Leopold Toetsch wrote:

>
> Ooch. Ok, here is the story: Parrot's current mark and sweep
> stop-the-world garbage collection isn't influenced by such code. *But*
> the "stop-the-world" can take arbitrary long and is rather slow with 
> the
> presence of huge amounts of objects.
>
> To get around the former an incremental mark & sweep collector is
> already working. The second problem can best be addressed by using
> a generational GC scheme.
>
> Both schemes have in common that they need a write barrier: this is a
> notification from the mutatur (the executing user code) that a pointer
> in an aggregate will be overwritten by a new one.
>
> This would look like this:
>
>    DOD_WRITE_BARRIER(interpreter, av, AvARRAY(av)[i], some_sv);
>    AvARRAY(av)[i] = some_sv;
>

Couldn't we just do a DOD_WRITE_BARRIER on the Array PMC and that 
should stop it from going into anything inside that aggregate storage.?

> Or as of Dan's proposal just all in one:
>
>    POINTER_STORE(interpreter, av, AvARRAY(av)[i], some_sv);
>
> The xvs are of course assumed to be PMCs already. The DOD_WRITE_BARRIER
> or the POINTER_STORE are macros that might be empty or do something
> depending on the objects states and on the implemented GC scheme.
>
> BTW: does Ponie have the Parrot interpreter structure available in the
> Perl context?
>


-----
Infrastructure Manager @ Fotango Ltd
+447834716919
http://www.fotango.com/