Hi Adam,
something like that could work, but there is still the problem that
you have to locate the object in memory in a heap, which will later on
be maintained by the GC. There are some low-level services, which IMHO
just can't be wrapped in object instances - as they are essentially
singletons. Memory management should be split into five pieces IMHO:
1. A physical memory manager, which gives out 4KB pages of physical
address space
2. A process memory manager, which manages virtual memory and acquires
physical pages on demand
3. A pager, which moves virtual pages between disk and physical memory
4. A heap manager, which is responsible for the actual object allocation
5. A GC which returns regions to the heap
At least #1,3 are singletons with respect to system lifetimes. #2,4,5
are per-process singletons.
Maybe we could think about your design of using adapter or strategy
objects to wrap the access to these services in your design? This way
the adapters could implement the interfaces you need and abstract away
the access to the actual service implementations.
Mike
Am 20.07.2008 um 00:34 schrieb Adam Stevenson:
Howdy Mike,
I am thinking what we need to do is figure out what format the
objects are going to need to look like in memory when a memory
manager / GC are in place. This way, when the MM and GC come online
during the boot up, they can "take over" objects that were
previously not managed, and the initial memory manager can keep a
list of memory allocated that is not yet been assigned to a memory
manager - thus making it easy to identify objects. Think this
approach could work? If so, we just need to figure out how we want
to structure the unmanaged memory / objects, so that their
structures can be compatible.
-Adam
On Sat, Jul 19, 2008 at 5:21 AM, Matthijs ter Woord <[EMAIL PROTECTED]
> wrote:
Ah, you guys are trying to instantiate the memory manager. Hmm..
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On Behalf Of grover
Sent: zaterdag 19 juli 2008 11:31
To: sharpos-developers@lists.sourceforge.net
Subject: Re: [SharpOS Developers] Memory manager designand
overallcompartmentalization
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&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
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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
