in reply to Re: Re: On timely destruction?
in thread On timely destruction?

Assorted comments:

I've read for years that the field of gc is quite mature, and some killer algorithms exist (way beyond simple mark&sweep).

How is access kept local? Chasing all the pointers would hit all that main memory, even if the marks are collected somewhere central.

I like the idea of incremental garbage collection, so there will be no pauses.

What about the case of local variables that never have their ref taken, and are not inside a closure that itself gets "taken"? If detected at compile-time, those can be stacked most efficiently and not generate garbage at all.

On a machine with VM, must figure out when is "out" of memory! I can use gobs more than the machine has, transparantly to the program. Perhaps moniter page fault frequency? Best to check for garbage before a page gets swapped out at all.


Replies are listed 'Best First'.
Re: Re: Re: Re: On timely destruction?
by Elian (Parson) on Aug 28, 2002 at 19:46 UTC
    In order:
    • Yes, there are a number of algorithms well-past the old mark & sweep. Throwing their names around isn't much use since most people are barely (if at all) familiar with m&s, let alone generational or threaded collectors of various sorts
    • Base structures are all allocated out of arenas, and most pointers to other base structures come from structures in the arena, so we're not walking through all of memory, instead usually being restricted to the arenas.
    • We don't currently have an incremental collector, though there's no reason we can't have one in the future. (The easy stuff first, after all... :)
    • The compilers are certainly within their rights to explicitly destroy variables. Given how introspective perl can be, though, that's not always wise. (With, say, caller %MY peeking and such)
    • We allocate memory out of pools. Out of memory for us is when we have no more pool space, not when the system has no more memory handy. (Memory usage can be restricted this way as well, but that's a side benefit)