| |||||||||||||
1978 called, wants its garbage collectors back1978 called, wants its garbage collectors backPosted Sep 4, 2008 16:17 UTC (Thu) by BrucePerens (guest, #2510)In reply to: 1978 called, wants its garbage collectors back by rwmj Parent article: The Kernel Hacker's Bookshelf: UNIX Internals This is a matter for much religious argument, although in cases like the kernel it's probably not a significant use of time or resources. Reference counting can be bug-prone, if you aren't using a language like C++ where it can be entirely automated. It is deterministic, uses very small slices per iteration, and works well at interrupt level. Even with reference counting, GC may be necessary to take care of a circular reference. I prefer a double-indirect system with reference counting and occasional GC, because it can resolve the fragmentation problem. CPUs could be built to optimize this similarly to the way they handle TLBs.
(Log in to post comments)
1978 called, wants its garbage collectors back Posted Sep 4, 2008 16:36 UTC (Thu) by rwmj (subscriber, #5474) [Link] 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.
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.
|
|||||||||||||