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*?
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.
For memory management, we obviously need to store tables of allocations,
(even if sparsely stored, such as by linked lists). The memory management
needs to be flexible enough that you give it the pointer to the root entry
for a given area of memory, and it be able to act in a black-box fashion for
that area of memory.
And obviously, garbage collection is an issue. But garbage collection is
also an issue when dealing with managed types and the references between
them. So how do we fit in a garbage collector that can clear primitives from
the heap, but can also handle objects on the heap that have runtime headers?
And then paging. I'm sure we might want our paging algorithms to be
interchangeable, as any other driver on the system. And even if we don't,
how closely will the paging be related to the scheduler? They will need to
cooperate, (though not necessarily be intimately familiar with each other).
I know this is a handful of issues to bring up at the same time, but we need
an open dialog about these issues because they seem to be pretty related.
-Bruce
aka Illuminus
-------------------------------------------------------------------------
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
