gc_massacre branch is ready for merging.

[Andrew Whitworth]

This is something I have always said, that we should try to make
Parrot's GC more precise and stop stack walking. But, that's not
something we can do now (or, likely within a few months).

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.

If we do things this way, we open the possibility that the user may
have stored a reference to a destroyed PMC somewhere, and attempts to
reference a recycled PMC later. However, if we leave it to the GC to
attempt to collect it at the next sweep, it might not be destroyed at
all, and may be kept on life support like is shown in bacek's example.

At the very least, I agree with marking the test TODO for now. It's
not a behavior we should be testing, at least not with such a small
test.

--Andrew Whitworth



On Wed, Sep 22, 2010 at 8:12 PM, Vasily Chekalkin <bacek at bacek.com> wrote:
> Hello.
>
> Example is not so artificial. It is what actually happening on
> gc_massacre branch:
>
> Break point to find out PMC address:
>
> Breakpoint 1, Parrot_FileHandle_nci_open (interp=0x8051040, _self=0x20)
>    at src/pmc/filehandle.c:201
> 201         PMC * const _ctx         = CURRENT_CONTEXT(interp);
> (gdb) n
> 202         PMC * const _ccont       = Parrot_pcc_get_continuation(interp, _ctx);
> (gdb)
> 203         PMC * const _call_object = Parrot_pcc_get_signature(interp, _ctx);
> (gdb)
> 214                 &_self, &filename, &got_filename, &mode, &got_mode);
> (gdb)
> 220         if (!Parrot_io_is_closed_filehandle(interp, _self))
> (gdb) p _self
> $3 = (PMC *) 0x80e1a28
>
>
> Breakpoint to find out moment when PMC marked as alive. Stack frames
> 3,4 and 5 show that PMC address found on C stack.
>
> Breakpoint 3, gc_ms2_mark_pmc_header (interp=0x8051040, pmc=0x80e1a28)
>    at src/gc/gc_ms2.c:688
> 688         ASSERT_ARGS(gc_ms2_mark_pmc_header)
> (gdb) bt
> #0  gc_ms2_mark_pmc_header (interp=0x8051040, pmc=0x80e1a28)
>    at src/gc/gc_ms2.c:688
> #1  0xb7df5188 in Parrot_gc_mark_PMC_alive_fun (interp=0x8051040,
>    obj=0x80e1a28) at src/gc/api.c:157
> #2  0xb7dff816 in trace_mem_block (interp=0x8051040, mem_pools=0x0,
>    lo_var_ptr=3221222396, hi_var_ptr=3221221496) at src/gc/system.c:474
> #3  0xb7dff400 in trace_system_stack (interp=0x8051040, mem_pools=0x0)
>    at src/gc/system.c:248
> #4  0xb7dff361 in trace_system_areas (interp=0x8051040, mem_pools=0x0)
>    at src/gc/system.c:217
> #5  0xb7dfe2c7 in Parrot_gc_trace_root (interp=0x8051040, mem_pools=0x0,
>    trace=GC_TRACE_FULL) at src/gc/mark_sweep.c:227
> #6  0xb7dfd1db in gc_ms2_mark_and_sweep (interp=0x8051040, flags=4)
>    at src/gc/gc_ms2.c:996
> #7  0xb7df6148 in Parrot_gc_mark_and_sweep (interp=0x8051040, flags=4)
>    at src/gc/api.c:662
> #8  0xb7da8eb1 in Parrot_sweep_ic (cur_opcode=0x80e4f44, interp=0x8051040)
>    at src/ops/core_ops.c:16124
> #9  0xb7e4c851 in runops_slow_core (interp=0x8051040,
>    runcore_unused=0x80d9098, pc=0x80e4f44) at src/runcore/cores.c:647
> #10 0xb7e4b8aa in runops_int (interp=0x8051040, offset=0)
>    at src/runcore/main.c:219
> #11 0xb7e0db8f in runops (interp=0x8051040, offs=0) at src/call/ops.c:127
> ---Type <return> to continue, or q <return> to quit---
> #12 0xb7e0802b in Parrot_pcc_invoke_from_sig_object (interp=0x8051040,
>    sub_obj=0x80dc580, call_object=0x80dc804) at src/call/pcc.c:324
> #13 0xb7ded643 in Parrot_ext_call (interp=0x8051040, sub_pmc=0x80dc580,
>    signature=0xb7f52e2e "P->") at src/extend.c:322
> #14 0xb7dea3d2 in Parrot_runcode (interp=0x8051040, argc=1, argv=0xbffff4d8)
>    at src/embed.c:812
> #15 0xb7f2d229 in imcc_run_pbc (interp=0x8051040, output_file=0x0, argc=1,
>    argv=0xbffff4d8) at compilers/imcc/main.c:415
> #16 0x080490a5 in main (argc=2, argv=0xbffff4d4) at src/main.c:156
>
> --
> Bacek
>
> On Thu, Sep 23, 2010 at 9:59 AM, Vasily Chekalkin <bacek at bacek.com> wrote:
>> Hello.
>>
>> Ok guys, problem is much deeper.
>>
>> Imagine some code like this:
>>
>> void main() {
>>   int z = 0xsomeaddress;
>>   Parrot_run_pbc(...)
>> }
>>
>> where PIR/PBC file contains something like this:
>>
>> .sub main
>>  $P0 = new 'FileHandle'
>>  needs_destroy $P0
>>  sweep 0
>> .end
>>
>> If address of $P0 is happen to be same as content of variable "z" from
>> C code than during tracing roots in C stack GC will mark $P0 as alive
>> and will not destroy it.
>>
>> So, current schema of timely destruction is unreliable and can't be
>> used anywhere else small tests.
>>
>> I strongly suspect exactly this happening on Darwin/i386 and causing
>> test failure.
>>
>> So, we should deprecate current "timely destruction" schema and design
>> new one which will guarantee actual destruction of PMCs at particular
>> point of time.
>>
>> In terms of branch merging I can just skip this test.
>>
>> --
>> Bacek
>>
>>
>> On Wed, Sep 22, 2010 at 9:31 PM, James E Keenan <jkeen at verizon.net> wrote:
>>> Vasily Chekalkin wrote:
>>>>
>>>> Hello.
>>>>
>>>> I fixed c++ build and filehandle.t failure. I'm not sure about
>>>> packfile failure on win32.
>>>
>>> t/pmc/filehandle.t test 22 is still experiencing the same test failure on
>>> Darwin/PPC as previously reported in gc_massacre branch, updated to r49243.
>>>
>>> So the branch is not ready for merging.
>>>
>>> Thank you very much.
>>> kid51
>>>
>>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>