[...] 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?)
[Jonathan Dickinson] Methinks that any code that cannot be JITted or AOTted in a platform agnostic fashion should be placed in the kernel. 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). [Jonathan Dickinson] Practically a requirement. The point of classical DLLs is that the /code/ is only loaded once (AFAIK .Net DLLs are identical in that respect). Obviously, we would need to apply further optimisations on that paradigm in the sense that memory is cheap these days, if an app uses a bit of code a lot it would be faster to duplicate it near to the code requesting it: so that they are in the same page. (One of the features of a feature rich CLR environment: page optimisation). 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? [Jonathan Dickinson] Yes, that is an issue. Rule of the thumb is: code pages should also have a read-only lock (which will increase security because buffer overflows would cause a GPF). So what are we looking at is (as in, the entire memory space): ------ KERNEL ---------- System.DLL ------------------------ System.Windows.Forms.DLL ------------------------ MyApp.Exe --------------------------- MyApp.Exe Data (Instance 1) --------------------------- MyApp.Exe Data (Instance 2) --------------------------- ... FREE ... --------------------------- Remember, a dll shouldn't really have any data (each variable in the DLL is contained in MyApp.Exe data space). This is all possible because the OS is OO: but it will require re-wiring of memory addresses at runtime. What you all think? Jonathan Dickinson ------------------------------------------------------------------------- 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
