| |||||||||||||
1978 called, wants its garbage collectors back1978 called, wants its garbage collectors backPosted Sep 4, 2008 16:36 UTC (Thu) by rwmj (subscriber, #5474)In reply to: 1978 called, wants its garbage collectors back by BrucePerens Parent article: The Kernel Hacker's Bookshelf: UNIX Internals
It is deterministic, uses very small slices per iteration [...] But is it? Is there not a case where you're freeing up blocks "deterministically" and then the block you just freed happens to complete a large hole and kfree/free suddenly goes off and does a lot of work to update its internal structures? (Or the corresponding case when allocating). These costs are often minimized by proponents of manual allocation. There's a rather well-known paper about this which goes into the subject in a lot of detail, and comes to some mixed conclusions. (Mind you, the benefit of GC is it massively simplifies programming and removes a huge source of error, which they don't take into account). Rich.
(Log in to post comments)
1978 called, wants its garbage collectors back Posted Sep 4, 2008 17:10 UTC (Thu) by vaurora (guest, #38407) [Link] Your description made me curious so I skimmed the paper. I wouldn't describe this as a "mixed conclusion": When garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collections performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. I'm afraid five times the memory consumption is not an option for the kernel. Your point about removing a source of programming error is well taken, but more applicable to random user space widgets.
1978 called, wants its garbage collectors back Posted Sep 4, 2008 17:12 UTC (Thu) by BrucePerens (guest, #2510) [Link] Is there not a case where you're freeing up blocks "deterministically" and then the block you just freed happens to complete a large hole and kfree/free suddenly goes off and does a lot of work to update its internal structures? I don't see how GC would improve that situation. It's reasonably trivial to code a kernel allocator that doesn't go into some loosely-bounded task at interrupt level. GC has its own errors, especially if it's the kind that assumes any word might be a pointer.
|
|||||||||||||