On Mon, 2005-10-17 at 21:07 +0200, Marcus Brinkmann wrote: > At Wed, 12 Oct 2005 13:24:35 -0400, > "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > > > On Wed, 2005-10-12 at 18:29 +0200, Ludovic Courtès wrote: > > > <[EMAIL PROTECTED]> writes: > > > Guile for instance could certainly make good use of > > > libhurd-mm's hooks, things of that sort... > > > > If you are thinking about using memory management in support of garbage > > collection, forget it. The literature on this is pretty comprehensive > > and mostly negative. > > This is interesting. We have always used three example applications > for the need to increase quality of service by providing more control > over physical resource usage: > > 1. Databases > Stonebraker "Operating System Support for Database Management" > > 2. Garbage Collectors > (eg A.W. Appel and K. Li. Virtual Memory Primitives for User Programs.) > > 3. Continuous Media applications > (eg G.E. Mapp An Object-Oriented Approach to Virtual Memory Management) > > These are the three examples given in Steven Hand: "Self-Paging in the > Nemesis Operating System". Maybe the result in 2. is not universal. > Even if not, this would still leave the first and third applications > as important fields to explore. > > Anyway, we would be interested in some references about the negative > results for garbage collectors.
The canonical place to start on garbage collectors would be Paul Wilson's survey paper. Alternatively, you might look at the book "Garbage Collection" by Jones and Lin, which is fairly comprehensive. The Wilson survey is generally considered definitive. The long and short of it is that the page fault handler latency is so high on most operating systems that it is much cheaper to use compiler-inserted barrier code. You might look in particular at Tony Hosking's paper: Protection Traps and Alternatives for Memory Management of an Object-Oriented Language. Keep in mind that his result is considerably understated. It could be that the reduced page fault handling times in a true microkernel would make a difference, but it is unlikely that a major implementer of a language runtime would want to do a special-purpose implementation for a niche target. I concur about databases, though I believe that the major issue there is resource isolation -- preventing the I/O driven by one client from decaching the work done my a second. The thing about continuous media is tempting to believe, and I certainly think that if you have the primitives you can do a better job than if you don't. The problem with this as a rationale is that Windows Media Player (WMP) does, in fact, work. On the server side it's a serious issue, and it's a serious issue if you want predictable media handling under constrained resource, but for the general client case it seems like a claim that would be hard to convince my mother to believe after MS demonstrates WMP. Just my quick thoughts... shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
