On 9/23/07, Bruce <[EMAIL PROTECTED]> wrote:
> On 9/23/07, Sander van Rossen <[EMAIL PROTECTED] > wrote:
> I don't know what you mean by layering. But these systems are definitely
> inter-dependent.

well paging is rough memory management (on blocks of memory),
malloc/free is a more fine grained memory management which using
pages.. if we had a garbage collector that used malloc/free it would
have to go trough 2 layers of data structures and algorithms/code to
work with memory..
That's what i ment with layering..

> But you probably don't want to keep it all in the same table, right?
> Different GCs for different process spaces.

There was a discussion about this some time back, there where some
good arguments against a global garbage collector...
So yes, in my opinion a GC for each process seems like a good idea imho.
Keeping everything in the same table would only be possible if the
table would have knowledge of all the types defined in all the
assemblies.. which would make loading/unloading assemblies much more
complicated..

> Which brings up an issue I forgot for my original e-mail: assuming paging is
> in place, what, and how much, do we share across different process spaces?
> Obviously, we have to store both data and memory. But how do we decide what
> is shared and what isn't? Compiled code? Perhaps we manipulate paging to
> send messages to the kernel? Lots of issues here.

Singularity does a whole program compilation & optimization with every
application and all the libraries and generates an executable with it.
So singularity doesn't have any shared code.
But i guess since we also would like to, eventually, be able to run
.net code written on other platforms, and maybe even dynamically
created assemblies (which singularity doesn't support), so i guess we
won't go in that direction..

If we assume that all applications are protected from eachother and
can't possibly modify memory which they don't own, then they can't
modify code either.
Which means that code could safely be shared (as long as they're in
the same 'hardware isolated process')
I guess we need different policies for different types of applications
(safe / unsafe etc.)

As for data.. if we have a garbage collector for each process.. then
only the garbage collector would really know which piece of memory is
what..
Which means the garbage collector, obviously, has to play a part in IPC.
It also means that reserving memory for a process has to be regulated
at a higher level, and on that level we have no knowledge of the data
in it.
The pieces of memory do not need to be next to eachother.. altough it
would be better to avoid memory fragmentation when applications are
executed / closed

Hmm.. does that mean we need a malloc/free + paging after all?
Better try to finely tune memory usage to avoid overhead..

> Yes, but for a vtable to be useful, we have to decide how we are storing
> stuff on the heap, and how we are storing references to the heap, onto the
> stack. We really can't do any work on the korlib or the VM until the AOT and
> the kernel can meet, on the grounds of vtables and memory management.
> ...
> We would need heap management, paging, and a korlib, at minimum, to run
> anything that you can think of in the terms of a normal .NET executable.
> korlib is optional, but we *have* to have memory management...

Most definitely.
So, any ideas on heap management?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers

Reply via email to