On Mon, Aug 15, 2005 at 15:59:34 +0100, Adrian Howard wrote:
> On 15 Aug 2005, at 13:17, Yuval Kogman wrote:

> I'm not sure what you're proposing here. A separate arena for
> stuff  you want to allocate and not be moved by the GC? How would
> I tell the  compiler?

You won't, the language glue is responsible for setting that up for
you, and it does that by assuming it's always there, and the
compiler simply optimizes the cases where it's never going to be

> How about
>      do : GC::priority(:new) {
>          # only GC things allocated during the lifetime
>          # of the block
>      }

I think that's not "priority" but "limit" or "scoped" or
"origin(:local)" or something like that...

Let's define some terms:

        scope/origin - where objects are created

        priority - how important is it that garbage is collected
        (high priority == more cpu use, less ram use)

        delay - pauses in the main flow that have nothing to do with
        priority. No delay could mean less performaance, but more
        responsiveness. Applicable to event loops and such.

        timelyness - the property of an object such that it's
        finalization subroutine is called the moment it becomes
        unreachable. This is important for objects using finalizers for
        resource management, especially when an unreleased resource
        could cause deadlock.

        finalization - the act of calling an object's finalize
        subroutine, and the release of it's memory.

The aspects of control we need:

        scope - which objects get cleaned up

        priority - what performance tradeoffs we want to make

        delay - whether or not the normal program flow will ever be
        paused when it is known that no timely objects need to be
        destroyed. Also possibly the maximum amount of time (in
        milliseconds?) that a GC iteration may take.

        timelyness - whether all objects, some objects (That are marked
        using 'but' or by their class), or no objects should be checked
        for timely destruction

        finalization - whether objects should be cleaned up at all

> Actually, since to my naive eyes it looks like the GC is a first
> class object the problem can probably be solver better by adding
> your  own.

Well, as I see it the GC is a subobject of the runtime. The amount
of control that this object can give you can be checked using the
strong support for reflection that perl 6 will have, or by simply
asking the runtime to switch GC (if it lets you do that).

 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: uhm, no, I think I'll sit this one out..: neeyah!

Attachment: pgp8madRhKWJZ.pgp
Description: PGP signature

Reply via email to