Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> What design issues are crying for attention right now?
I forgot another related issue in my previous mail. In
Subject "Scope exit and timely destruction" I've written:
> Given is a Perl snippet like:
> {
> my $fh = IO::File->new;
> $fh->open(">test.tmp");
> print $fh "a";
> }
> The filehandle is closed automatically at scope exit and the file
> contains the expected contents.
> That's quite easy in the current Perl implementation as it does
> reference counting. At the closing bracket the last reference to
> C<$fh> has gone and the file gets closed during object destruction.
> As parrot isn't using reference counting for GC, we have to run a GC
> cycle to detect that the IO object is actually dead. This is
> accomplished by the "sweep 0" opcode, which does nothing if no object
> needs timely destruction.
> Above example could roughly translate to Parrot code like:
> new_pad -1 # new lexical scope
> $P0 = new ParrotIO
> store_lex -1, "$fh", $P0
> open $P0, "test.tmp", ">"
> print $P0, "a"
> pop_pad # get rid of $fh lexical
> sweep 0 # scope exit sequence
> Alternatively a scope exithandler could be pushed onto the control
> stack.
> With such a sequence we got basically two problems:
> 1) Correctness of "sweep 0"
> At scope exit we've somewhere in the PMC registers the ParrotIO
> object still existing. This means that during marking the root set,
> the ParrotIO object is found being alive, where it actually isn't.
> The usage of registers keeps the object alive until this register
> frame isn't referenced anymore, that is after that function was left.
[ snipped performance considerations ]
There was some discussion about GC and performance, but the main problem
wasn't addressed at all.
The implication for me is that we can't keep the current register frame
layout anyway. As long as the register frame of the scope is around, the
ParrotIO object is kept alive. That is: we have to use one register
frame per variable scope like we have one frame per subroutine now.
leo
