Re: [SharpOS Developers] Additional stuff regarding memory

[Sander v. R. <s.v...@sy...>]

That's exactly what i was talking about before, when talking about
keeping "book-keeping information" in memory when swapping pages to
disk.
That way you know if blocks of memory (which are currently on disk)
need to be collected or not.
This way you wouldn't even have to touch the memory blocks... if
they're collected, then the page is freed in the page file, if it's
not collected.. nothing happens.
Only problem is that the book-keeping information (which specifies
which object is connected to which, and what block of memory on disk
it uses) costs memory itself.. so it should only be used on reasonably
large blocks.
Trashing to and from disk would *really* decrease the performance of
virtual memory.. and make collections a nightmare performance wise...

On Tue, Aug 5, 2008 at 1:07 PM, grover <sh...@mi...> wrote:
> Zach,
>
> You're right. Current GCs tend to trash the disk if they try to
> collect a heap that's mostly paged out. I was hoping we can
> prevent this kind of behavior by applying some smarts there. Actually
> I think the chances are actually good there as pages could be removed
> from memory on a LRU scheme - we could try to collect these specifically
> to throw them away before paging them out.
>
> Mike
>
>> -----Ursprüngliche Nachricht-----
>> Von: sha...@li...
>> [mailto:sha...@li...] Im
>> Auftrag von Zachary Gorden
>> Gesendet: Dienstag, 5. August 2008 12:39
>> An: sha...@li...
>> Betreff: Re: [SharpOS Developers] Additional stuff regarding memory
>>
>> In response to Sander:
>>
>> A valid point, regarding the reserved space.  However, I was
>> thinking that the drivers were also restricted to the upper
>> 2GB with the kernel.  Actually, this is the point where you
>> guys tell me how you want to approach this separation of
>> drivers thing.  After all, sticking all the drivers into
>> their own address space is not the way to go in my opinion.
>> Minix does this and they suffer a 20% performance penalty in
>> the process.  I don't fully understand how Singularity does
>> it, so, yeah.  After all, the point of Singularity's design
>> was to avoid that penalty.
>>
>> I talked to a friend of mine who has a better idea of how GCs
>> work.  Apparently GCs do not care whether their heaps are
>> paged out or whether there's a lack of physical pages.  It's
>> entirely possible for it to try to sweep heaps that are
>> completely paged out, causing performance issues and etc.
>> Now granted the OS can provide ways of telling whether a page
>> is in memory or not, there are other complications.  Anyways,
>> I don't expect some kind of global GC or something.  I expect
>> each appdomain to have its own.  But since the 2GB range (or
>> whatever it ends up being) for the application's personal
>> usage is separate for each appdomain anyways, then what's the
>> problem with shifting all responsibility to the GC and the
>> managed heap?  Again, that's all stuff that needs to be thought about.
>>
>> Forcing GC across the board really would be an act of
>> desperation, to be honest.  But we'll see.
>>
>> In response to Grover:
>>
>> Well, originally I was thinking about an all or nothing
>> approach.  But to be perfectly honest, appdomains sharing
>> address spaces have almost nothing to do with the work I need
>> to do in the lower levels.  I'm just providing the ability to
>> create address spaces for each appdomain.  The MM provides
>> the services and people implementing the higher level stuff
>> can worry about keeping things straight.  Correct me if there
>> is something I need to take into consideration though.
>>
>> The stuff you suggested for basic functionality the MM
>> provides through its interface will most likely be present
>> for use by whatever is managing the heap.
>>
>> In Windows, the bootloader actually handles all of the
>> mapping of the kernel into virtual memory using page tables.
>> It's one reason grub can't natively boot Windows (the other
>> being the registry).  Freeloader, the ReactOS bootloader,
>> actually would be capable of doing this too, but we'd need to
>> write the code for it to understand the SharpOS kernel.
>>
>>
>
>
> -------------------------------------------------------------------------
> 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
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>