Cool, good to see that someone has put some time into the basics of a design.
My responses are meant as positive criticism, and meant to start a dialog, not to force my opinion onto anyone. I -expect- people to come up with counter arguments. Hopefully trough this dialog we can come up with a good design. That being said: > Virtual Address Space Organization > > The virtual address space in SharpOS will follow the traditional 2GB split > for kernel and user mode > in 32bit mode, however this is a mere formality, as there does not exist a > user mode. > It is more for organization purposes so that the kernel has sufficient > reserved space for its own > data structures. The only thing prevent applications and other unauthorized > code from accessing > the kernel portion will be the managed nature of such code. Does that still make sense with a micro-kernel? After all, we're not talking about a monolithic kernel which uses a ton of resources, we're talking about a lot of smaller interconnected pieces which each use a relatively small amount of resources... 'kernel' and 'user' mode don't really exist, at least not in the traditional sense, since we'd use a more detailed rights model to determine what a process may or may not do. If you consider the libraries as 'the kernel' then this split would make more sense. (We really need better terminology when it comes to this) Also, we wouldn't want to expose all libraries to all appdomains.. basically only the ones they'll be using, yet we do want to share the code-memory of libraries between appdomains. (The memory pages containing the libraries should also be set to read-only, but i hope that's obvious to everyone here...) > The kernel range will be the traditional upper 2GB of the 4GB virtual space. > It will be a series of preallocated paged and unpaged pools of memory, > specifically set aside for usage by the kernel. Sounds a bit much for 'the kernel'. Keep in mind all the drivers etc. will be outside 'the kernel' and inside 'user mode'.. > The lower 2GB reserved for the application is where things get interesting. > Because everything the application does is managed, we might be able to > shift almost all responsibility to the GC and company. It requires some > thought, as I don't know what is intended for management of application > memory. That's sounds rather vague, and we'll need regular heaps for things like inner-process communication as well. although arguably, this would be part of 'the kernel'. Also, we'd want a GC for every process separatly, it would allow much quicker releasing of the memory of a process when it shuts down, and would also keep the GC generations much smaller and easier to manage. Imagine having to do a system wide garbage collection! You'd have to freeze the -entire- system and walk trough -all- the objects in -all- the processes! every time! > Okay, I'm lying. What I really want to know is when people keep saying "GC > kicks in when memory is low," what the blazes do they mean? > Are they talking about the GC being aware of physical pages actually running > low? > Or just this heap that the GC is supposedly managing, which might as well > be a range of virtual addresses that might all be paged out for all we know? > Until that point gets cleared up, I'm stuck as to what I need to provide for > the upper level services. It's gonna be tricky, especially since we need to mix virtual memory that's been paged to disk with memory that's used in the garbage collector.. And we don't want to have to read all the memory back from the page file to determine what can be collected. We might be forced to swap whole processes to and from disk instead of pieces of memory that haven't been used in a while. Or restrict it to large blocks of memory (but keep some small book-keeping information in memory to be able to walk trough the process to see what's still 'used' and what needs to be collected) As for when to garbage collect.. i suppose there are some thresholds that when crossed would trigger a collection.. the most obvious ones are when there's not enough memory available to allocate some memory for a process, or when the system is (relatively) idle you do a collection (to prevent a collection occurring when the system is hard at work), or before (part of) a process is written to the page file (to prevent memory being written to the page file which isn't actually used anymore anyway) We'd need some way to assign and collect pages of memory from processes as well, and a way to force other processes to do a collection when memory is full and a process needs more memory (and hopefully another process would release some memory after a collection).. > The tricky part we now have to deal with is the initial mapping of the kernel > into > virtual address space and putting together a page table for it. I still > don't fully > know how I'm going to pull it off, but it will definitely require some > refactoring > of the code. I also need to pick a point early enough in the loading where > I won't be overwhelmed with repointing all the pointers. Don't worry to much about the refactoring at this point, we need a good design first, and only then should we worry about making it reality.. ------------------------------------------------------------------------- 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
