Re: Q: scope exit
Dan Sugalski [EMAIL PROTECTED] wrote:
But that still doesn't solve the problem that a file-handle (after
cleaning lexicals) is still in a PMC register, when the Csweep 0
opcode is run.
True but, and this is the good part, that's not our problem. It is, I
think, safe to assume that language compilers that want timely
destruction will make sure to clean up after themselves sufficiently
to make that timely destruction possible. It's our job to provide the
mechanisms they need, and leave it to them to use them as needed.
In other words, we punt it to someone else. :)
I'd prefer such a solution too. But:
{
my $fh = open(..);
foo(1, $h);
}
which could be some PIR like:
new_pad -1
$P0 = Pio.open()
store_lex -1, $fh, $P0
foo(1, $P0);
pop_pad
sweep 0
with some corresponding PASM (pdd03 call registers ignored for brevity)
new_pad -1
set P2, Px
callmethodcc open
set P16, P5
store_lex -1, $fh, P16
set I5, 1
set P6, P16
set_p_pc P0, foo
invokecc
pop_pad
sweep 0
Now we have the filehandle scattered and duplicated in P registers. There
is no chance for a HLL to emit null Px to clear involved registers as
the information, where each temp is located, isn't available.
At scope exit the filehandle is alive in registers and not closed.
leo
Re: Q: scope exit
On Tue, Dec 14, 2004 at 10:49:31AM -0500, Dan Sugalski wrote: Yes. I'll presume that the first Perl6 compiler will just emit closures for each block. Ah, I hope not. I *really* hope not. (Paying attention Patrick? :) That'd be rather slower than necessary in most cases. Yup, I'm paying attention. :) While we might just emit closures for each block in the earliest development versions of the Perl6 compiler just to get things going, I wouldn't expect it to stay that way for very long. Certainly I don't think we'll be long past that by the time we reach a 6.0.0 release of the compiler. It is, I think, safe to assume that language compilers that want timely destruction will make sure to clean up after themselves sufficiently to make that timely destruction possible. It's our job to provide the mechanisms they need, and leave it to them to use them as needed. Agreed, with the caveat that we may discover we need some additional mechanisms as work progresses. But it's a little early to try to get it perfect right now -- we'll just cross our bridges when we get to them. The important thing will for the compiler writers and Parrot implementers to be able to adapt quickly when we find the things we all overlooked. Pm
Re: Q: scope exit
Dan Sugalski [EMAIL PROTECTED] wrote: At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote: * What is the intended usage of the action handler? * Specifically is this also ment for lazy DOD runs? * How is the relationship to the Cpop_pad opcode? The one thing that I figure *will* be done is that languages will push a sweep or collect op in their scope cleanup in those cases where the language knows that there's potentially easy temp cleanup that needs doing, for example filehandles that should be closed when the scope's exited if there are no outstanding references to them. That'll not be really easy: [ subroutine frame ] | | [ cleanup handler subroutine frame ] If the cleanup handler is a plain subroutine, the previous one, which should be cleaned, is alive. A lazy DOD will find the filehandle in the lexicals and likely in registers. It seems that we have to do kind of a tailcall to the cleanup handler and that we've to nullify PMC registers of the subroutine that called the cleanup handler. But that would make the cleanup handler useless for other tasks, like actively closing some resources. Doing this right needs a precise definition of the semantics of such a cleanup handler. leo
Re: Q: scope exit (was: Exceptions, sub cleanup, and scope exit)
At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: ... A scope exit action is put in place on the control stack with: pushaction Psub * What is the intended usage of the action handler? * Specifically is this also ment for lazy DOD runs? * How is the relationship to the Cpop_pad opcode? The action handler is there to provide the languages as a way to do something when scopes are left. It's a generic 'out' for stuff that we've not thought about. Most scope exit stuff is cleanup which we'd rather be done via the DOD/GC system (otherwise things go Horribly Wrong in the face of continuations) but there may well be things that need doing. The one thing that I figure *will* be done is that languages will push a sweep or collect op in their scope cleanup in those cases where the language knows that there's potentially easy temp cleanup that needs doing, for example filehandles that should be closed when the scope's exited if there are no outstanding references to them. (And I know we've got the aggressive GC system for things like that, but in most cases languages can use something a bit less aggressive -- do a full sweep to clean up anything that's actually dead, and anything that escapes scope can be picked up later, since it's lifetime's probably gone nondeterministic) As far as pop_pad goes, I think maybe we need to revisit the control stack ops to see if some of them can go. (There are a fair number of rough draft things in the pad handling design that need editing) Possibly push_pad too, which could be handled with pushaction, or come up with a lighter-weight scheme to do something similar. Or it may be that there are few enough things that it's worth keeping push/pop_pad around. Not quite sure right now, but we should nail that one down. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Q: scope exit
At 10:19 AM +0100 12/14/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote:
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the relationship to the Cpop_pad opcode?
The one thing that I figure *will* be done is that languages will
push a sweep or collect op in their scope cleanup in those cases
where the language knows that there's potentially easy temp cleanup
that needs doing, for example filehandles that should be closed when
the scope's exited if there are no outstanding references to them.
That'll not be really easy:
[ subroutine frame ]
|
|
[ cleanup handler subroutine frame ]
Which does argue that it ought not be a sub, I suppose, but something
simpler. A plain bsr sort of thing.
If the cleanup handler is a plain subroutine, the previous one, which
should be cleaned, is alive. A lazy DOD will find the filehandle in the
lexicals and likely in registers.
Well, maybe. Subs are going to have multiple scopes in them (which
argues for a faster-than-sub cleanup handler dispatch) so it's more
than just a 'cleanup before leaving the sub' sort of thing. There's
an awful lot of code around that looks like:
sub foo {
# Insert code here
foreach (@some_array) {
}
{
# Some code that needs its own block
}
if (foo) {
} else {
}
}
Besides cleaning up on sub exit, there's also a potential cleanup
when the foreach is left, the bare block is left, and each of the
legs of the if are left. (Potentially once on each foreach iteration,
I suppose)
Also, since the compilers are in control of when things get
established when entering a sub, if they've noted that there's a
reason for a cleanup handler they can push one before establishing
the lexical pad it needs to clean up after so that pad'll be disposed
of before the cleanup handler runs. (Or, I suppose, two can be
pushed, one for before and one for after, if it's noted that's needed)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Q: scope exit
Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:19 AM +0100 12/14/04, Leopold Toetsch wrote:
Which does argue that it ought not be a sub, I suppose, but something
simpler. A plain bsr sort of thing.
A bsr doesn't change anything. It has to return to the caller. That
thing, where it's returning to, is alive.
If the cleanup handler is a plain subroutine, the previous one, which
should be cleaned, is alive. A lazy DOD will find the filehandle in the
lexicals and likely in registers.
Well, maybe. Subs are going to have multiple scopes in them (which
argues for a faster-than-sub cleanup handler dispatch) so it's more
than just a 'cleanup before leaving the sub' sort of thing. There's
an awful lot of code around that looks like:
sub foo {
# Insert code here
foreach (@some_array) {
}
{
# Some code that needs its own block
}
if (foo) {
} else {
}
}
Besides cleaning up on sub exit, there's also a potential cleanup
when the foreach is left, the bare block is left, and each of the
legs of the if are left. (Potentially once on each foreach iteration,
I suppose)
Yes. I'll presume that the first Perl6 compiler will just emit closures
for each block. But if no handle on this closure is kept they'll likely
end up as nested scopes. For both we need a sequence:
pop_pad
sweep 0
this could be one opcode (the pop_pad isn't needed, if it's a sub exit)
scope_exit
But that still doesn't solve the problem that a file-handle (after
cleaning lexicals) is still in a PMC register, when the Csweep 0
opcode is run.
leo
Re: Q: scope exit
At 3:31 PM +0100 12/14/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:19 AM +0100 12/14/04, Leopold Toetsch wrote:
Which does argue that it ought not be a sub, I suppose, but something
simpler. A plain bsr sort of thing.
A bsr doesn't change anything. It has to return to the caller. That
thing, where it's returning to, is alive.
I'm only concerned about overhead here. Live-ness is a separate
issue. (An important one, but separate. That's dealt with below)
If the cleanup handler is a plain subroutine, the previous one, which
should be cleaned, is alive. A lazy DOD will find the filehandle in the
lexicals and likely in registers.
Well, maybe. Subs are going to have multiple scopes in them (which
argues for a faster-than-sub cleanup handler dispatch) so it's more
than just a 'cleanup before leaving the sub' sort of thing. There's
an awful lot of code around that looks like:
sub foo {
# Insert code here
foreach (@some_array) {
}
{
# Some code that needs its own block
}
if (foo) {
} else {
}
}
Besides cleaning up on sub exit, there's also a potential cleanup
when the foreach is left, the bare block is left, and each of the
legs of the if are left. (Potentially once on each foreach iteration,
I suppose)
Yes. I'll presume that the first Perl6 compiler will just emit closures
for each block.
Ah, I hope not. I *really* hope not. (Paying attention Patrick? :)
That'd be rather slower than necessary in most cases.
[Snippage]
But that still doesn't solve the problem that a file-handle (after
cleaning lexicals) is still in a PMC register, when the Csweep 0
opcode is run.
True but, and this is the good part, that's not our problem. It is, I
think, safe to assume that language compilers that want timely
destruction will make sure to clean up after themselves sufficiently
to make that timely destruction possible. It's our job to provide the
mechanisms they need, and leave it to them to use them as needed.
In other words, we punt it to someone else. :)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Q: scope exit (was: Exceptions, sub cleanup, and scope exit)
Dan Sugalski [EMAIL PROTECTED] wrote: ... A scope exit action is put in place on the control stack with: pushaction Psub * What is the intended usage of the action handler? * Specifically is this also ment for lazy DOD runs? * How is the relationship to the Cpop_pad opcode? Thanks, leo
