Re: Garbage Collector API
David Formosa wrote: 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
Re: Garbage Collector API
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.). 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 [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me beats up some cheese: neeyah! pgpGT8KHLqMjI.pgp Description: PGP signature
Re: Garbage Collector API
On 26 Jul 2005 05:18:05 -, David Formosa ) [EMAIL PROTECTED] 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. -- 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.
Re: Garbage Collector API
On Thu, Jul 28, 2005 at 01:08:13 -, David Formosa (aka ? the Platypus)
wrote:
On 26 Jul 2005 05:18:05 -, David Formosa )
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpIYCYY9JrLG.pgp
Description: PGP signature
Re: Garbage Collector API
On Thu, 28 Jul 2005 16:22:19 +0300, Yuval Kogman [EMAIL PROTECTED] wrote:
[...]
On Thu, Jul 28, 2005 at 01:08:13 -, 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).
--
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.
