Matthijs, you're right. However it still doesn't solve the problem that you
want to new a memory manager without having a memory manager to allocate one
from ;) SharpOS doesn't have a GC with the current memory management
facilities either. I see it more of a structural problem than a technical
one and thus I see it more like a design issue.
Mike
_____
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von
Matthijs ter Woord
Gesendet: Samstag, 19. Juli 2008 11:04
An: sharpos-developers@lists.sourceforge.net
Betreff: Re: [SharpOS Developers] Memory manager designand
overallcompartmentalization
An option is maybe this:
Make a fake memory manager, which only is able to allocate (ie, it never
takes back memory). For most basic operations you don't use too much
objects, so you can live without a GC for a while too. This way you can
start on Object support, then interface support, while not having issues
with GC and memory manager.
We do it that way in Cosmos. We don't have a memorymanager capable of
freeing memory, neither do we have a GC (we have the code in place to plug
one in, but don't have one. Ralf just started on this)..
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
grover
Sent: zaterdag 19 juli 2008 10:16
To: sharpos-developers@lists.sourceforge.net
Subject: Re: [SharpOS Developers] Memory manager design and
overallcompartmentalization
Hi Adam,
the AOT does support interfaces. There were some bugs, but they shouldn't
stop us there. There's only one problem: For interfaces to work you need
object instances and new/GC... Which causes us a kind of chicken & egg
problem. At least at the level Zachary is working at, we need to stay with
static classes. I understand your goals, but unless you can give me a hint
how you want to manage it without the chicken&egg situation I don't have any
idea.
Mike
_____
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von
Adam Stevenson
Gesendet: Freitag, 18. Juli 2008 06:44
An: sharpos-developers@lists.sourceforge.net
Betreff: Re: [SharpOS Developers] Memory manager design and
overallcompartmentalization
Howdy Zachary and All,
Yes, I believe that we do need to do a good restructruring. I have a bunch
of ideas I have been hashing out in my sandbox, but I there are parts that I
am not sure exactly what is going on (some parts get cryptic, any understand
the process of preparing the image fully?). I first think we need a high
level diagram of all the major components, so we can start figuring out
where we can make plugable modules. From my own project work, and my
experience with biologcial systems, we need to slowly evolve this and not
break it. (I know duh).
First does thing support interfaces yet? Because I don't see much of them
in the code base. If not, I say we work on making a list of abstract
classes that we can start keying in as modules. I know Grover has been
working on a lot of this, and we need to get his input on the AOT plugable
architecture. Anyone going to be around Sunday afternoon (CST) - or most
anytime Monday (minus 3:00 to 5:00 CST)? I can sit down online with anyone
and start diagraming some of this stuff and work a bit in team mode -
identify document, and review. And then we can send out whatever documents
we get done via the list serve, and continue to move on ot the next. Anyone
up for it?
As for what I have been working on is a bunch of class processing stuff, and
memory structuring of components. I want to build an architecture that you
could say is "fractal" - thus allowing for the same archtiecture whether a
JIT is being ran on top of a JIT (pretty dang inefficient) or is actaul the
JIT. To do this, everything needs to be turned into an interface, to allow
for components to shift up and down. I have started looking into how to
structure this namespace and working on a prototype base, but it is not
compable yet (on my to do list for next week). But bottom line, this is
still a long way off from where the AOT and SharpOS is now, so this is by
now means a fully workable design that SharpOS can be converted too. Plus
there are some differences in concepts too with the idea of runtime and OS
that are going to have to be hashed out.
So personally, we need to look at all of us "newbies' fully understanding
what we have, and second we slowly turn this thing modular and make a list
of all the modules and what their requirements are, so the code base can be
evolved in small parts versus changing one thing causes a bunch of ripple
effects throughout the code. My guess, a lot of this modularity already
exists, but we just need to uncover dividing points. So back to Sunday and
Monday for me. Anyone game? And thoughts on how we want to start breaking
up this code base into smaller understandable pieces? Oh Zachary, I got
both those books on Memory Management and Garbage Collection - need to
finish them, but if you have concepts to reference, just let me know page
numbers.
Adam Stevenson
Graduate Student
Department of Biology
Texas A&M University
College Station, TX 77843, USA
On Wed, Jul 16, 2008 at 10:03 AM, Zachary Gorden <[EMAIL PROTECTED]>
wrote:
Just a clarification, when I say memory manager, I mean from the page tables
to the physical memory table to the allocations. It seems that people keep
confusing what I am referring to whenever I say MM. This is mostly an
informational thing to let people know what's going through my head and the
fact that I'm not dead and still working/planning.
The memory manager as it stands suffers from a somewhat awkward design that
makes it difficult to correct certain items. Not exactly anyone's fault, as
SharpOS needed a MM and that's what it got. The gist is, trying to fix the
issues in here and/or optimizing it won't do much in the long term, which is
one reason you guys haven't seen much activity from me.
I've been mostly consulting a few ROS developers on how to bootstrap a page
table based MM, the initial loading and stuff, so that's the explanation for
the lack of code. For the time being, I've gotten most of the conceptual
things explained and will be writing out some of my own code as well as
examining just what kind of support for paging exists right now. And
actually, in the process of trying to look at the current code, another
thought occurred to me. Currently, the ADC is, to put it simply, horribly
organized. It's basically all of the AD code in one spot, without any
actual segmentation. That is definitely going to screw with us down the
line, and it is likely to not be limited to the ADC.
Because of the above reasons, I am most definitely going to need to create a
branch (once I figure out how), as obviously doing surgery on trunk is going
to result in incredible instabilities and breakages. But as far as the
restructuring goes, I think a lot of us would benefit from such changes,
including people already working with their own branches. I'd like to hear
from other people on the restructuring idea, as I know I'm not the only one
who noticed the issues.
-------------------------------------------------------------------------
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
<http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
-------------------------------------------------------------------------
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
