Conditional DOD runs
Dan Sugalski
destruction, or something very much like it, mainly filehandles and
other external resource holders. (Though there are the odd games that
people do like to play with scope exit actions from deeper levels)
So, we might as well finalize that. What I'm going to do is add
another flag to the set, PObj_is_impatient_FLAG, and some code to the
DOD to tally up the objects with this flag set, a field to the
interpreter structure (impatient_things), and a new op (lazysweep)
that triggers a sweep only if there are objects that really want it,
as well as an op (impatient) that marks a PMC as impatient.
It's distinctly possible that this will add some unpleasant overhead
to things, but we're already flag checking so I'm hopeful it won't.
If it does we may have to reconsider how it should work.
How this works is simple. Compilers for languages that *care* about
timely destruction should insert this op into the stream where it
seems appropriate, probably as part of scope exit. Languages that
don't care won't, and that's fine. If you return a perl filehandle to
a ruby routine, then the filehandle may not get immediately destroyed
when the ruby routine exits its scope, but that's fine as that's not
guaranteed in ruby. Perl, OTOH, since it *does* care, will issue
these ops and check more frequently.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Zellyn Hunter
> So, we might as well finalize that. What I'm going to do is add
> another flag to the set, PObj_is_impatient_FLAG, and some code to the
> as well as an op (impatient) that marks a PMC as impatient.
Okay - I know I speak with no authority (as a lurker) and this might be
entirely too picky, but it seems to me that marking an object as "impatient"
isn't as clear as it could be - if I ran across a PObj_is_impatient_FLAG I
would be left wondering what exactly the object is impatient *for*.
How about PObj_impatient_for_dod_FLAG or something like that? It's a bit
long, isn't it? Any ideas?
On the other hand, I believe there are lots of references to "magic" in
Perl5's internals... and perhaps it's fine to use a nice clear word for
things like that - you can pretty much assume that anyone who has to ask what
it means shouldn't be messing with it anyway.
I'm not sure impatience and magic should ever be mixed, though.
Yours,
Zellyn Hunter (that's Mr. Zellyn Hunter to any list summarizers reading this)
Q: How many Parrot programmers does it take to screw in a lightbulb?
A: Just one, as long as it's Leo Toetsch. He will probably also rewire your
entire electrical system slightly, saving you about 3% in power consumption
during the evenings and on weekends.
Leopold Toetsch
> How about PObj_impatient_for_dod_FLAG or something like that? It's a bit
> long, isn't it? Any ideas?
Better a longer name stating what is intended then some shortcut.
> Q: How many Parrot programmers does it take to screw in a lightbulb?
> A: Just one, as long as it's Leo Toetsch. He will probably also rewire your
> entire electrical system slightly, saving you about 3% in power consumption
> during the evenings and on weekends.
Thanks, but no - a lightbulb is hardware so I'd not touch it ;-)
leo
Peter Haworth
> So, we might as well finalize that. What I'm going to do is add another
> flag to the set, PObj_is_impatient_FLAG, and some code to the DOD to tally
> up the objects with this flag set, a field to the interpreter structure
> (impatient_things), and a new op (lazysweep) that triggers a sweep only if
> there are objects that really want it, as well as an op (impatient) that
> marks a PMC as impatient.
Is the impatient_things field a flag, a count or something else entirely?
Presumably it is kept up to date on a real time basis in order for lazysweep
to make the correct decision. If it's a count, this is basically the
refcounting overhead, but restricted to operations which change
PObj_is_impatient_FLAG, or which free up PMCs with it set. If it's a flag,
the GC system has to set/clear it after checking every single PMC in the
system, and make sure that nothing else could have set it in the meantime.
--
Peter Haworth p...@edison.ioppublishing.com
"First, there are no rules; second, if you break any of
them, you will be treated to some classic British sarcasm"
-- uk.rec.climbing FAQ
Dan Sugalski
>On Tue, 20 May 2003 15:30:27 -0400, Dan Sugalski wrote:
>> So, we might as well finalize that. What I'm going to do is add another
>> flag to the set, PObj_is_impatient_FLAG, and some code to the DOD to tally
>> up the objects with this flag set, a field to the interpreter structure
>> (impatient_things), and a new op (lazysweep) that triggers a sweep only if
>> there are objects that really want it, as well as an op (impatient) that
>> marks a PMC as impatient.
>
>Is the impatient_things field a flag, a count or something else entirely?
Both. (And I remembered to check in this morning)
There's a flag on the PMC. Every time it's set, a counter in the
interpreter structure is incremented. A DOD run recalculates the
count.
>Presumably it is kept up to date on a real time basis in order for lazysweep
>to make the correct decision. If it's a count, this is basically the
>refcounting overhead, but restricted to operations which change
>PObj_is_impatient_FLAG, or which free up PMCs with it set. If it's a flag,
>the GC system has to set/clear it after checking every single PMC in the
>system, and make sure that nothing else could have set it in the meantime.
While I'm not thrilled about the DOD runs checking for the flag on
every PMC, they're already scanning all the PMCs anyway as they make
the sweep of the arenas looking for newly dead PMCs, so we're already
doing that.
Dan Sugalski
>In perl.perl6.internals, you wrote:
>
>> How about PObj_impatient_for_dod_FLAG or something like that? It's a bit
>> long, isn't it? Any ideas?
>
>Better a longer name stating what is intended then some shortcut.
Definitely. I checked in the code with the short name just so I could
make sure it got in, but renaming is in order.