Hi Zach, Some answers inline below.
> -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im > Auftrag von Zachary Gorden > Gesendet: Dienstag, 5. August 2008 09:39 > An: sharpos-developers@lists.sourceforge.net > Betreff: [SharpOS Developers] Additional stuff regarding memory > > Decided to get off my ass and provide some more detailed > thoughts about what's needed for the memory system. So far, > this is more a matter of intentions than set plans. It also > raises some points I don't fully understand and would > appreciate insight on. > > SharpOS Memory Architecture Design > > This is a basic outline of the low level memory management > system of SharpOS. This does not include the higher level > garbage collection and managed memory schemes, but the basic > services that they will depend on. > > 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. > > Using a separate page table for each appdomain will mean we > must change the value in CR3, so we will need to do a memory > context switch. This results in increased overhead and may > be avoidable in 64bit mode, but will require some > experimentation in the future. The page table entries > describing the kernel range will be shared by all page > tables. Intel processors have support for this so it > shouldn't be problematic. I think we can live with this, however I would not assume that an AppDomain is a process. This may be, but its not in a traditional .NET sense. We'd have to do lots of inter-process marshalling in a lot of common situations if we'd move AppDomains to their own address space. So here comes the requirement that AppDomains must be able to share address spaces. > 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. These preallocated data structures will need > some tweaking in order to ensure there is enough for each. > For allocations smaller than a page in size, there will be a > series of stacks of varying sizes. Allocations from them > will be done through lockfree atomic instructions to ensure > better throughput. Whether a general purpose pool will be > needed or even possible I'll have to look into, as > traditionally you cannot allocate to the heap like you would > in 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. > > 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. Like I wrote previously there's two parts to this: The actual allocator (a heap of some sort) and the GC itself. Heaps need to grow and when that happens a first-gen collection is performed, so that the crap pile of all temporary objects is freed on the heap. Then the allocation is tried again - if it fails this time, the heap must grow and the heap will request new pages. So the GC does not have much to do with you, its more the heap which needs to be able to allocate (batches) of pages and free them again. I see this similar to the VirtualAlloc/VirtualFree functions in Win32, an interface of that style should be sufficient. I would think of: - An alloc - A free - A low watermark notification - An info method to get statistics and page granularity - Ability to set page protection attributes (read, write, execute, no-execute) - Page status: Reserved, Committed, Freed, (Paged, ...) > 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. Does this have to do with grub? Do we need a different (managed?) boot loader? > Physical Memory > > This is basically the paging/swapping part. This is actually > fairly simple to work out, but does depend on a working > storage stack. However, we can start by putting together the > data structures that keep track of physical pages and make > use of the additional values in the structures once we're > able to. I honestly haven't given much thought to which > paging algorithm would be best, but there's so much research > out there we'll have plenty of help picking one. > > Closing Thoughts > > First and foremost, I'm hoping that we stick with an object > based design. My reason is centered around security, as > applying security when everything is an object is much > easier. That might not seem like it has anything to do with > memory, but trust me, it does. But we won't actually deal > with it until the basic virtual memory is done. I agree with you on this. ------------------------------------------------------------------------- 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
