add write barrier to all PMCs that write in unusual VTABLE functions

[cotto]

The new generational gc that bacek's been working on gives us some very nice performance benefits, but it also adds a new requirement to PMCs. src/vtable.tbl lists all known VTABLE function names, some of which are marked with :write. All other VTABLE functions usually don't mutate the state of their PMCs. Call these "non-mutating" VTABLE function.

Any PMC that implements a non-mutating VTABLE function in a way that mutates the PMC's internals now needs to use the PARROT_GC_WRITE_BARRIER macro on any PMCs that are modified, including SELF. This won't mean very many changes for most HLLs, but it can result in mysterious failures if neglected.

There's an implementation of PARROT_GC_WRITE_BARRIER in master now, so it can safely be added to any HLL that builds with the current Parrot without breaking anything.

[cotto]

Because of the significant benefit and relatively low cost to HLLs, we will likely be fast-tracking this deprecation and merging shortly after the 3.1 release. I'll bring this up at #parrotsketch on Tuesday for discussion.

[jkeenan]

Replying to cotto:

Because of the significant benefit and relatively low cost to HLLs, we will likely be fast-tracking this deprecation and merging shortly after the 3.1 release.

3.1 was 5-1/2 months ago. cotto, can we get an update on the status of this ticket?

Thank you very much.

kid51

[cotto]

GMS is the default and the two HLLs that needed write barriers were updated. I think that the main failure was to record that information here and to update api.yaml. Now that the ticket is updated, I'll close it.