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.