Garbage Collector API
David Formosa )
seperate thread.
We are should have an API to talk to the GC and give it hints about when it
should run, and tweek the verious paramitors for its running.
For example
use GC trigger => 10`percent;
GC::run(); # Trigger the Garbige collector to run at this moment
GC::exclude(&code); # Don't run the Garbige collector while &code is
being executed.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
David Formosa )
<dfor...@dformosa.zeta.org.au> wrote:
> We are should have an API to talk to the GC and give it hints about when it
> should run, and tweek the verious paramitors for its running.
>
> For example
[...]
Also
my Bigobjet $big is GC::timely = Bigobect; # Request timely
# destruction of $big. Usefull for filehandels and network
# resources.
Yuval Kogman
> On 26 Jul 2005 05:18:05 -0000, David Formosa )
> <dfor...@dformosa.zeta.org.au> wrote:
>
> > We are should have an API to talk to the GC and give it hints about when it
> > should run, and tweek the verious paramitors for its running.
> >
> > For example
>
> [...]
>
> Also
>
> my Bigobjet $big is GC::timely = Bigobect; # Request timely
> # destruction of $big. Usefull for filehandels and network
> # resources.
I like this approach the most: it let's users specify what they
need, not how they need it done.
Every GC has slightly different semantics. If we have a generational
GC that has delays, or a reference counting scheme that does
occasional reachability tests, it doesn't really matter.
What we want is features:
some object needs to die appropriately, because i'm using
DESTROY to manage resources, or trigger an action
And we can also open the door to optimizations:
some object is cheap to store, you can collect it later than
usual
everything under this object belongs to it, and only to it (that
is, you can cleanup the whole tree when cleaning this up)
and so on and so forth.
We do need this applying to:
roles and classes:
class Moose is GC::timely { ... }
a policy for attributes of objects:
class Moose {
has $. handles "method" is GC::timely; # not good enough, i
# want to be able to say "all children", and I want this to
# be inheritable... A class property, i guess
}
instances:
# your syntax is per container
my $big = $something but GC::timely; # do we have runtime 'does'? I keep forgetting
contained elements within a container
my @a is Array of (Item is GC::timely);
and containers themselves without respect to their contained:
my @a is Array is GC::timely
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
David Formosa )
[...]
> On Thu, Jul 28, 2005 at 01:08:13 -0000, David Formosa (aka ? the Platypus) =
> wrote:
[...]
>> my Bigobjet $big is GC::timely =3D Bigobect; # Request timely
>> # destruction of $big. Usefull for filehandels and network
>> # resources.
>
> I like this approach the most: it let's users specify what they
> need, not how they need it done.
I can see advantages to both approches. All GC systems have a hit
when they run, in some situations it would be nice to shift the hit to
times when it doesn't mattor that much. For example a GUI app may
delay the GC till when the user has been idle for a while.
> Every GC has slightly different semantics. If we have a generational
> GC that has delays, or a reference counting scheme that does
> occasional reachability tests, it doesn't really matter.
Yes thats why I was saying "hints". Not all hints are going to be
that meaningfull.
> What we want is features:
>
> some object needs to die appropriately, because i'm using
> DESTROY to manage resources, or trigger an action
Which I'm calling the timely trait.
> And we can also open the door to optimizations:
>
> some object is cheap to store, you can collect it later than
> usual
Sort of an anty timely? GC::tardy
> everything under this object belongs to it, and only to it (that
> is, you can cleanup the whole tree when cleaning this up)
GC::tombstone;
[...]
> We do need this applying to:
>
> roles and classes:
> class Moose is GC::timely { ... }
Yep (and yes to all your other suggestions).
Greg Buchholz
> I can see advantages to both approches. All GC systems have a hit
> when they run, in some situations it would be nice to shift the hit to
> times when it doesn't mattor that much. For example a GUI app may
> delay the GC till when the user has been idle for a while.
Has any thought been given to using a concurrent garbage collector
for Perl6? Besides eliminating GC pauses (which in turn means less of a
need for users to fiddle with the GC settings, and therefore a smaller
chance of accidently screwing it up), it might be one of the easier
sources of parallelism to exploit on multi-processor machines. And it
could open the door for more soft realtime applications in Perl (audio
processing, games, etc.).
Thoughts?
Greg Buchholz
Yuval Kogman
> Has any thought been given to using a concurrent garbage collector
> for Perl6? Besides eliminating GC pauses (which in turn means less of a
> need for users to fiddle with the GC settings, and therefore a smaller
> chance of accidently screwing it up), it might be one of the easier
> sources of parallelism to exploit on multi-processor machines. And it
> could open the door for more soft realtime applications in Perl (audio
> processing, games, etc.).
Well, the reason an API based on what an object requires, not how
it gets it is better is that it doesn't matter - the GC could be a
separate thread, and GC::timely could just be a blocking call to the
GC thread asking it to check of the said object needs to be
collected or not. This could be optimized for latency, so that just
the critical objects are checked first, and then everything is
cleaned up in the background.
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!
David Formosa )
<nothi...@woobling.org> wrote:
[...]
> On Mon, Aug 01, 2005 at 08:46:07 -0700, Greg Buchholz wrote:
>
>> Has any thought been given to using a concurrent garbage collector
>> for Perl6? Besides eliminating GC pauses (which in turn means less of a
>> need for users to fiddle with the GC settings, and therefore a smaller
>> chance of accidently screwing it up), it might be one of the easier
>> sources of parallelism to exploit on multi-processor machines. And it
>> could open the door for more soft realtime applications in Perl (audio
>> processing, games, etc.).=20
>
> Well, the reason an API based on what an object requires, not how
> it gets it is better is that it doesn't matter -
Then what I was calling GC::exclude(&CODE) should be called
GC::nodelay(&CODE) . ie I'm requesting that the Garbiage collector
doesn't cause a pause while &CODE is being executed. And leave the
reson why a pause doesn't happen to the implementor of the GC.