Zach, You're right. Current GCs tend to trash the disk if they try to collect a heap that's mostly paged out. I was hoping we can prevent this kind of behavior by applying some smarts there. Actually I think the chances are actually good there as pages could be removed from memory on a LRU scheme - we could try to collect these specifically to throw them away before paging them out.
Mike > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im > Auftrag von Zachary Gorden > Gesendet: Dienstag, 5. August 2008 12:39 > An: sharpos-developers@lists.sourceforge.net > Betreff: Re: [SharpOS Developers] Additional stuff regarding memory > > In response to Sander: > > A valid point, regarding the reserved space. However, I was > thinking that the drivers were also restricted to the upper > 2GB with the kernel. Actually, this is the point where you > guys tell me how you want to approach this separation of > drivers thing. After all, sticking all the drivers into > their own address space is not the way to go in my opinion. > Minix does this and they suffer a 20% performance penalty in > the process. I don't fully understand how Singularity does > it, so, yeah. After all, the point of Singularity's design > was to avoid that penalty. > > I talked to a friend of mine who has a better idea of how GCs > work. Apparently GCs do not care whether their heaps are > paged out or whether there's a lack of physical pages. It's > entirely possible for it to try to sweep heaps that are > completely paged out, causing performance issues and etc. > Now granted the OS can provide ways of telling whether a page > is in memory or not, there are other complications. Anyways, > I don't expect some kind of global GC or something. I expect > each appdomain to have its own. But since the 2GB range (or > whatever it ends up being) for the application's personal > usage is separate for each appdomain anyways, then what's the > problem with shifting all responsibility to the GC and the > managed heap? Again, that's all stuff that needs to be thought about. > > Forcing GC across the board really would be an act of > desperation, to be honest. But we'll see. > > In response to Grover: > > Well, originally I was thinking about an all or nothing > approach. But to be perfectly honest, appdomains sharing > address spaces have almost nothing to do with the work I need > to do in the lower levels. I'm just providing the ability to > create address spaces for each appdomain. The MM provides > the services and people implementing the higher level stuff > can worry about keeping things straight. Correct me if there > is something I need to take into consideration though. > > The stuff you suggested for basic functionality the MM > provides through its interface will most likely be present > for use by whatever is managing the heap. > > In Windows, the bootloader actually handles all of the > mapping of the kernel into virtual memory using page tables. > It's one reason grub can't natively boot Windows (the other > being the registry). Freeloader, the ReactOS bootloader, > actually would be capable of doing this too, but we'd need to > write the code for it to understand the SharpOS kernel. > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
