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.
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.
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.
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.
-------------------------------------------------------------------------
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
