Let's see if I can explain this thoroughly enough within the time limit I
have.
I have not given any real thought to anything higher than getting the page
table based memory system up and running. I have relatively little
experience dealing with GCs and I would like to remind everyone that in
effect, if we go one address space per appdomain, that entire address space
can become managed. Think about that for a second, as it presents some
interesting possibilities. Beyond that, I've given some thought to the
allocations the kernel itself needs to make to function. I know xfury and
some of the others have heard of my idea, specifically duplicating Solaris'
slab allocator using lock-free atomic instructions on a stack, of sorts.
That is the most ambitious I have gotten with my design work and it has
absolutely nothing to do with what traditionally would be "user mode"
stuff. Once, assuming I am skilled enough to, the foundations are in place
and virtual memory is basically working, that will be when we can figure out
how to handle and tweak the higher level services, or what higher level
services will be exposed.
The thing is, if an entire address space is managed, we're on a whole
different ball park. This little fact may well change how we make use of
the address space (or at least the part not reserved by the kernel), which
is one reason I haven't delved much into anything beyond the Allocate/Free
services that will be present. I personally don't know how having access to
the entire (almost) address space wile affect things, but it could present a
different way to organize the address space than what was done in the past.
This is why I really haven't given much thought to the higher level stuff,
since I really don't know what becomes possible. Don't underestimate what
this means, as at the least it might mean we could get away with having no
native allocation methods and give direct control to the various heaps and
stacks.
On Thu, Jul 24, 2008 at 12:00 AM, <[EMAIL PROTECTED]> wrote:
> What prevents us from using an interface for that purpose, which would
> consist of at least 3 functions:
>
> - IntPtr Allocate(uint size);
> - void Deallocate(IntPtr ptr);
> - bool Owns(IntPtr ptr);
>
> I think this serves a better purpose. Delegates are going to take a bit
> longer to implement as they require some non-trivial runtime support.
>
> Mike
>
> Bruce Markham schrieb:
>
> I'm going to agree with Jonathan on that one.
>
> I had talked along the same concept before - the idea of an allocation
> context - but it really boils down to the allocation and deallocation being
> delegates. (Or function pointers - depending on where in the kernel you are
> using them.)
>
>
> -------------------------------------------------------------------------
> 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
