One thing comes to mind. It's a bit in depth and close to implementation details, but the alloc function should be a pointer/delegate. For example: MemoryAllocator.Bootstrap(); Kernel.Boot(); Hal.Boot(); Hal.LoadBootstrap(); Pager.Boot(); MemoryAllocator.Allocate = Pager.Allocate; Hal.LoadAll(); ...
I know it is really diving into specifics but it makes sense to me from an architectural standpoint, thought i should throw it into the cauldron :). On 7/23/08, Sander van Rossen <[EMAIL PROTECTED]> wrote: > I like agree that we need multiple heaps and heaps should not be tied > too closely to the garbage collector(s). > > I like the idea of being able to 'take over' objects, and in fact i > think it's a necessity if we want to have stuff like exchange heaps. > The scary part is that we'll have objects in a process which would > belong to different heaps, so each object will need to be identifiable > as belonging to a certain heap. > If heaps are continuous blocks of memory this should be a matter of > checking if the object's address lies between the extends of the > heaps' memory block, if the memory of the heaps are not continuous > things can get pretty ugly quickly. > > note #1 > We should also think about debugging/profiling functionality when it > comes to heaps and garbage collections. > It would really be useful to eventually be able to 'freeze' a process > and walk trough it's heap and see which objects are still 'alive'. > Really useful to find objects still being connected to other objects > and not being collected because of it etc. etc. > Not to mention useful for debugging the heaps/GCs (and drivers!) in > the first place.. > In other words; debugging functionality should not be an afterthought. > > note #2 > I'd like to point out that there are the following Wiki pages: > > kernel design: http://www.sharpos.org/redmine/wiki/7/Kernel_Design > and more specifically: > memory management: http://www.sharpos.org/redmine/wiki/7/Memory_Management > (both are rather undeveloped to say the least) > > I suggest we actually write down whatever we reach (reasonable) > consensus on there so we actually have some documentation. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > SharpOS-Developers mailing list > SharpOS-Developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > -- Sent from Gmail for mobile | mobile.google.com Jonathan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
