This is highly ID TEN T, but how do I get the following code to work (is
anyone on IM):
private const int CONSOLE_MAX_LEN = 255;
private static CString8* currentCommand = new
CString8[CONSOLE_MAX_LEN];
Jonathan Chayce Dickinson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce
Markham
Sent: 11 November 2007 11:44 PM
To: SharpOS Developers
Subject: [SharpOS Developers] Memory Management | Paging
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
