From: Sander v. R. <san...@gm...> - 2007-07-22 11:16:44
|
Since i won't be able to attend the meeting, i'll just throw my 2cts in beforehand on some of the topics. About the whole "GC: use one GC for all SIPs (software-isolated processes) or one GC per SIP? " thing.. One GC per SIP is supposed to be more secure.. if this is really true, then i'd like to know why exactly. Can we work around it? (Would we even want to?) Is one GC per SIP simpler or more complicated? Theoretically having one GC for all SIPs would make it easier to optimize things, and to transfer memory from one process to another (great way to efficiently pass messages between processes)... but would the benefits outweigh whatever downsides we can come up with? Also, I can imagine that one GC for all SIPs would have less overhead then one GC for each SIP (which would have one extra thread for each SIP). On the other hand yesterday it was mentioned that if you have one GC per SIP it would be easier to prioritize the GC because higher priority GC's would have more cpu time, therefore have more cpu time for their garbage collector.. But should priority of a process have anything to do with memory, which is a system wide resource? The garbage collector is basically a resource manager which manages a shared resource between all processes. The process that allocates the most memory would get most of the time of the GC, the other processes wouldn't care as long as they get their requested memory. Also, a higher priority process would be able to request memory from the GC faster compared to a low priority process, simply because a higher priority process can do things faster... So that makes me feel the whole priority thing would work automatically.. Also, afaik (under win32 at least), allocation of memory under a GC is relatively cheap.. it's the cleanup which takes the most time. Actually the garbage collection is a kind of independent thing that doesn't really have much to do with the original process... it's just cleaning up it's mess.. If the GC is 'global' for all SIPs, it wouldn't matter whose mess it's cleaning up, it just sees a lot of objects in several different generations.. All that would matter is that there's enough memory left for all processes that need some memory and that the memory isn't too fragmented.. (and i guess, somehow, magically, avoid cache misses) But to be honest, i don't feel too strongly about one above the other, but i do think we should make a decision about this because of the right reasons, not because it's common practice, because SharpOS changes the rules somewhat because it's managed.. Personally, i suspect ultimatly we have to try both, unless someone comes up with a killer argument why a global GC simply wouldn't work or would be too dangerous (we already know that one GC per SIP would work) In the meantime i think it would be best to have one GC per SIP, for now, because SharpOS isn't developed enough to actually test the difference between a global GC and a local GC. (one per SIP) SharpWS - too bad i won't be able to discuss this in the meeting since this is one of the parts of SharpOS which interests me the most.. :( Kernel - i think we need some sort of client/server driver system framework so we can plugin our 'drivers' into the kernel (even if these drivers are included in the same assembly) It should be extremely lightweight and have only one layer imho. I guess i'll more to say after i read the transcript of the meeting tonight.. |