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
