LogicalError wrote...
> It's become a bit fuzzy what exactly the things where that i worked on
> before..
>
> But i remember that i basically got to the point where memory
> management just barely worked.
> The pageallocator is still a bit buggy though, especially the method
> with which you can allocate a range of pages is really buggy..
> (i don't have the code here, so i can't tell you the exact name of the
> method.. i think it's called rangealloc)
>
> Once the pageallocator is done, it can then be used in my (temporary)
> memory manager which can then be inited with a larger memory block.
> (right now it only uses one memory page)
[LONG (SPLIT UP) POST WARNING]
I've taken a look at some of it, and I'm quite impressed that we have, at
least some kind of, functionality off the ground. My problem is, memory
management terminologies and techniques are still rather new to me. So I
have trouble looking at the code and figuring out what is going on. But I
know we have a good handful of issues at hand (in my poor, ignorant eyes).
This, and the following to e-mails, regard such:
1. Paging: We have to be able to split memory up into pages, because
it will be required for virtual RAM later on. Sub-issues:
1. Paging abstraction: Do we need to expose paging methods
through the root ADC layer? (If so, like all memory management
issues, what
do we do about int32 vs int64 for 32 bit vs 64 bit architectures?)
2. MMU - what kind of ADC abstraction do we use to make sure the
MMU is aptly utilized?
3. Page Usage - do we want to isolate code in certain pages,
vtable/typeinfo in certain pages, and data in others?
1. Obviously, in some cases, page sharing would be very
cool - appdomains that share types could share certain pages
of memory (not
data memory though).
2. If we do use page sharing to share code and typeinfo
sections, we have to track who is using what - we can't
deallocate or update
a page if it is actively being used. (Some sort of synclock
mechanism would
be needed, I would think?) But we would want to be able to
lock a page, (
e.g. if a type is re-loaded/compiled), update it, and then
release the lock?
3. We have to deal with some sort of relative pointer
usage. I have no idea how pointers work in a mixed page
environment. Page A
and B are defined in Context 1. Context 2 defines Page C,
Page A, Page B,
and Page D. How do pointers in Page A to Page B, work, when
in Context 2,
Page A and Page B come later in memory?
4. How, or does, appdomains, interact with paging issues? Or
will we keep the appdomain abstraction above and beyond paging? (I would
assume we would.)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
