Garbage Collector API

15 views
Skip to first unread message

David Formosa )

unread,
Jul 26, 2005, 1:18:05 AM7/26/05
to perl6-l...@perl.org
So the summerizor doesn't get upset with me, I'll restate this in a
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 )

unread,
Jul 27, 2005, 9:08:13 PM7/27/05
to perl6-l...@perl.org
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.

Yuval Kogman

unread,
Jul 28, 2005, 9:22:19 AM7/28/05
to David Formosa (aka ? the Platypus), perl6-l...@perl.org
On Thu, Jul 28, 2005 at 01:08:13 -0000, David Formosa (aka ? the Platypus) wrote:
> 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 )

unread,
Jul 28, 2005, 9:59:42 AM7/28/05
to perl6-l...@perl.org
On Thu, 28 Jul 2005 16:22:19 +0300, Yuval Kogman <nothi...@woobling.org> wrote:

[...]

> 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

unread,
Aug 1, 2005, 11:46:07 AM8/1/05
to perl6-l...@perl.org
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

Yuval Kogman

unread,
Aug 1, 2005, 3:08:52 PM8/1/05
to Greg Buchholz, perl6-l...@perl.org
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 <nothi...@woobling.org> 0xEBD27418 perl hacker &

/\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!

David Formosa )

unread,
Aug 1, 2005, 6:26:23 PM8/1/05
to perl6-l...@perl.org
On Mon, 01 Aug 2005 22:08:52 +0300, Yuval Kogman
<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.

Reply all
Reply to author
Forward
0 new messages