Hi I did alot of reading lately. And I wanted actually to write an email about the need to implement a basic memory manager ASAP even if there is no GC or a way to free the memory, for the beginning.
Another thing that I thought about lately was about including the metadata into the binary so that I can start the work on reference types. But that again needs the memory manager to allocate the objects on the heap. I don't want to talk the importance of the scheduler down, or the work that Sander van Rossen did (which is fantastic). But we should concentrate more on the Memory Manager, as a single threaded/single process for the 0.0.1 release is ok, IMHO. Chriss. PS: The AOT generates now a PE for the kernel only. Generating PE for other purposes is possible, though there are a couple of things that are still missing (e.g. relocations and so on). Chriss. Sander van Rossen 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.. > 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 > > ------------------------------------------------------------------------- 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
