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