On 9/23/07, Sander van Rossen <[EMAIL PROTECTED]> wrote:
>
> On 9/23/07, Bruce <[EMAIL PROTECTED]> wrote:
> > Hello everyone:
> >
> > As I was looking over the kernel, and re-reading some x86 documentation,
> a
> > few issues have piqued my interest: paging, memory management, and
> garbage
> > collection. I know that xfury has done preliminary work in all three of
> > these areas, but I'm wondering, where are we going with this?
>
> You bring up a good point, we really need a design.
> I'm already experimenting a bit with a scheduler to try out some ideas.
>
> > Basically, what I'm trying to get an idea of, is what the pipeline for
> > malloc() and free() calls, (generated by the AOT to provide runtime
> support
> > for the VM.) We have three ways in which this memory allocation is
> needed:
> > For EIC code in the kernel (such as string buffers for the Console
> support
> > of the demo kernel), for letting AOTed EDC code run in the kernel (so
> that
> > we can get korlib, and eventually the VM, off the ground), and for
> managed
> > JITed code.
>
> I'm not so sure if it's a good idea to have multiple layers of memory
> managers
> (meaning, paging, malloc/free, garbage collection), because every
> layer will create extra overhead..
I don't know what you mean by layering. But these systems are definitely
inter-dependent. As far as "layered" memory management - its pretty much the
same whether you are allocating stuff for the kernel, or allocating stuff
for some app somewhere. But you probably don't want to keep it all in the
same table, right? Different GCs for different process spaces.
Which brings up an issue I forgot for my original e-mail: assuming paging is
in place, what, and how much, do we share across different process spaces?
Obviously, we have to store both data and memory. But how do we decide what
is shared and what isn't? Compiled code? Perhaps we manipulate paging to
send messages to the kernel? Lots of issues here.
On the other hand it seems useful to me to have different garbage
> collection algorithms for different applications..
> (In fact, singularity compiles a garbage collector with each
> application in a whole program optimization phase)
> And we need a way to separate memory from one application to another.
> We also need a way to transfer memory (and copy objects) from one
> application to another for IPC, which is also a very important part
> which we need to design because we'll need to to abstract the drivers
> and applications from the kernel.
Yes, definitely.
There are a lot of things that we could/should abstract, such as the
> scheduler algorithm, the garbage collector, the drivers (obviously)
> etc.
>
> It seems to me that we really could use vtable support in the engine
> (as well as memory management), then we can finally stop hacking
> around the many limitations that we have right now.
> (exception handling would also be nice, but we can do without for a while)
>
Yes, but for a vtable to be useful, we have to decide how we are storing
stuff on the heap, and how we are storing references to the heap, onto the
stack. We really can't do any work on the korlib or the VM until the AOT and
the kernel can meet, on the grounds of vtables and memory management.
By the way, can the AOT also build non-kernel executables?
> We could, for the time being, add AOT compiled applications to the
> kernel as resources which we could then run in the kernel for testing
> (when scheduling works)
We would need heap management, paging, and a korlib, at minimum, to run
anything that you can think of in the terms of a normal .NET executable.
korlib is optional, but we *have* to have memory management...
And if we have heap/memory management, and the korlib, we might as well go
ahead and drop the VM (which is the AOT having AOTed itself) in there
anyway.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
