gc_massacre branch is ready for merging.

[Andrew Whitworth]

Right, so we really have two options:

1) We have a "timely" destruction, which isn't timely and isn't
predictable or useful
2) We explicitly kill PMCs when we want them dead, and risk keeping
references around for later.

A third option would be to VTABLE_destroy the PMC and morph it into a
Null PMC in-place. Anybody still referencing it will get a Null PMC
exception, but won't crash. We still get freed resources, just not
freed PMC headers. The PMC_IS_NULL macro would have to grow a little,
of course.

--Andrew Whitworth



On Wed, Sep 22, 2010 at 8:36 PM, Vasily Chekalkin <bacek at bacek.com> wrote:
> Hello.
>
> On Thu, Sep 23, 2010 at 10:31 AM, Andrew Whitworth
> <wknight8111 at gmail.com> wrote:
>> Changing our mechanism for timely destruction would be good. I've
>> always thought it felt a little flimsy. I'm not sure what we want to
>> replace it with. Maybe a "destroy_and_null" opcode, which would
>> destroy the PMC and null the contents of the register to prevent
>> accidental reuse. Or, we can attach PMCs needing timely destruction to
>> a context or Sub, and when the Context/Sub exits, we destroy all the
>> attached "eager" PMCs.
>
> In CPS VM there is no difference between "call" and "return". However
> we have explicit C<returncc> so we can attach "list of pmcs to
> destroy" to CURRENT_CONTEXT and implicitly destroy them. Only one
> problem - if someone attach "live" PMC from outer context to "destroy
> list" we will crash. Epically.
>
> --
> Bacek
>