On Mon, 15 Aug 2005 15:17:18 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote:
[...]

>> 2) Some way of being able to tell the garbage collector to ignore
>> the  current contents of the heap for the purposes of GC. One
>> Pop-11 idiom  was to do something like: 

[...]

> We are trying to design a requirement based interface, so that the
> GC can be changed, but behavior remains consistent.
> 
> This should be more like 
> 
>               do :GC::priority(:low) {
>                       # anything that isn't GC::timely or possibly affecting
>                       # something that is GC::timely is not cleaned up till
>                       # later
>               }

I don't think that making use of "use" and "no" would be shorter and
far more Perlish.  Also this allows us to switch off the
modifications. 

So this would be

{
  use GC::priority :low;
  # anything that isn't GC::timely or possibly affecting
  # something that is GC::timely is not cleaned up till
  # later
}
 
>               do :GC::nodelay {
>                       # the GC can work, but timeliness and throughput are
>                       # ignored for the sake of performance of "real" code
>                       # this means that most GCs are disabled, but a
>                       # background thread GC will just have it's priority
>                       # lowered
> 
>                       # implies that 'timely' now means 'at some point'
>               }

{
  no GC::delay;
  ...
}


>               do :GC::nodestroy {
>                       # the GC is told to completely freeze the state of
>                       # things, delaying all work until after the block exits
>                       # this means that you can rely on GC::timely objects
>                       # being alive even when they shouldn't be.
> 
>                       # this is orthogonal to GC::nodelay - under plain
>                       # GC::disabled objects may be collected for overall
>                       # performance reasons, and then simply put on the
>                       # finalize queue for finalization on block exit.
> 
>                       # applying both nodelay and nodestroy causes the GC
>                       # system to completely turn off, so that objects are
>                       # neither finalized nor collected.
>               }

{
  no GC::destory;
  ...
}

> 
>               do :GC::disabled {
>                       # nodelay and nodestroy together
>               }

{
  no CG::destory;
  no GC::delay;
  ...
}

# Or

{
  no GC;
  ...
}

>               do :GC::priority(:high) {
>                       # work very hard to conserve memory
>               }

{
    use GC::priority :high;
    ...
}

>               do :GC::critical {
>                       # it's like GC::timely for everything
>               }

I'm not sure "critical" is the right name.

[...]

>> 3) Some way of marking structures/fields so their reference doesn't  count. 
>> Weakrefs basically.
> 
> Yes... i think this is a container trait. Anybody got an opinion?
> 
>       my $var is weakref = $object;

is GC::weak

> This is getting me thinking though:
> 
>       $*RUNTIME.Memory.GarbageCollector.dispose($object); # force it,
>       # even if it should be alive

Isn't that what we have undefine(...) for?

>       $*RUNTIME.Memory.GarbageCollector.clean($object); # check it

Possably as an argument for GC::delay(...) ?


-- 
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.

Reply via email to