Re: Patches that will come...

Tim Bunce <[email protected]> wrote:
> On Thu, Sep 02, 2004 at 09:28:58AM +0200, Leopold Toetsch wrote:
>>
>> Is there XS code around that directly manipulates aggregates? E.g.
>>
>>   AvARRAY(av)[i] = some_sv;

> Yes. (The DBI and drivers for a start.)

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;

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?

>> or is it enforced to use the interface:
>>
>>   Perl_av_store(av, i, some_sv);

> No. But active module maintainers would make that change to ease
> migration if it was required.

It will be required.

> Tim.

leo