| |||||||||||||
Module unloading in a reference counted worldModule unloading in a reference counted worldPosted Jan 29, 2004 2:23 UTC (Thu) by flewellyn (subscriber, #5047)Parent article: Module unloading in a reference counted world
Refcounting? Come on. Why not a kernel-level garbage collector? Besides being better from a performance standpoint (refcounts are expensive to update all the time), this would also help resolve a lot of these circularity problems. And it'd make the Lispers happy, too. :-)
(Log in to post comments)
Module unloading in a reference counted world Posted Jan 29, 2004 7:40 UTC (Thu) by nix (subscriber, #2304) [Link] Of course, there *is* a kernel-level garbage collector, but it's for AF_UNIX sockets. :)
Garbage collector Posted Jan 29, 2004 15:50 UTC (Thu) by rwmj (subscriber, #5474) [Link] Yes, just what I was going to post :-)All of these problems that the kernel developers keep reporting were solved back in the 60s and 70s by garbage collectors which are *more efficient* than hand allocation. Rich.
Module unloading in a reference counted world Posted Jan 29, 2004 21:52 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257) [Link] Any garbage collecting scheme has to be implementable on all architectures (like ref counting is), not too punishing on the cache (like ref counting is), and fairly small and simple (like ref counting).Despite its disadvantages, ref counting still has (and will perhaps always have) its place. In particular, the number of counts for modules is probably quite low, and fairly static, so that inc/decref performance issues aren't much concern (but cache issues are). Circular dependencies may be the bigger problem, but even then, in the limited domain of kernel modules, one that might be addressed in a straightforward way. However, I welcome comments about what specific advantages other garbage collecting schemes might offer.
|
|||||||||||||