Skip navigation

Category Archives: SharpOS

Very much aligned with the fact that the control bitmap technique was wholly unsatisfactory, last night I changed the page allocator I’m working on to use the free page stack technique. I even wrote the code to allocate a range of contiguous physical pages. I still must finish paging and the basic memory mapping API.

I’ve started work on the memory manager implementation for SharpOS. Mostly this is because it hasn’t been done yet and I will need the functionality to test any of the other code (SharpOS.EIC and SharpOS.Runtime) using the SharpOS AOT compiler.

Using various internet resources I have hacked together what is a mega-basic page allocator. It uses the provided Multiboot information to determine the amount of RAM, and the offset/size of the kernel must be passed to MemoryManager.Init(). Using this information, it sets up a bitmap for control information on the first page past the end of the kernel, and reserves the pages below 0x100000 as well as the pages occupied by the kernel. The only thing left to implement for a basic page allocator is the Alloc/Dealloc, which is a matter of binary search.

The allocator also handles setting up 2-level paging and enabling it, but right now it does not relocate anything–so physical == virtual. I’d like to put the kernel in the higher half, but that requires modifying the segment base pointer so that we don’t have to relocate pointers (would be tedious). I think I need the AOT’s help to manipulate the segment base pointer at the right time (compile-time?).

Of course, the bitmap is not an ideal method of memory management. The bitmap search will be slow once lots of memory is allocated, and I’m looking into various ways of improving the performance. One method I’ve seen is to use another control bitmap for ‘superpages’ which represent large blocks of pages. Another method is to use a stack of free pages and just pop and push pages to it for allocation. This is a much faster way of allocating, but apparently gets difficult when allocating contiguous pages. I believe it is the method used by Linux and Windows NT though, which lends credence to the concept.

More later!

I’m currently working on a garbage collector written in C# for the SharpOS project. It’s an interesting project as the code must avoid making use of new managed objects to keep track of the old ones. Without managed objects I’m left with two possibilities–deal directly with unmanaged memory space and pointers or I can have the runtime have all objects explicitly implement an interface which includes the size of the GC tracking data in the size to be allocated. So the GC indirectly allocates the resources necessary to track it implicitly. This work is dependent on having a VMM to handle paging, swapping, etc. Chriss said he looked into it and will handle writing it. The GC code I have currently implements all the appropriate System.GC methods/members which are useful.

I’m following a site that lists the basic compacting/generational GC design. I’ll write more as I make the code more capable.