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
