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.
