From: Sander v. R. <san...@gm...> - 2007-07-22 11:13:15
|
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.. |
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.. |
From: Maciej J. <him...@o2...> - 2007-07-22 21:30:51
|
Sander van Rossen wrote: > Congrats with your brother ;) Brothers, thanks. > SharpWS stands for Sharp Windows System, it will be a while before > it'll be even close to operational tough... we don't even have > graphics in SharpOS... > ... at least: not yet :) Sweet. Yesterday I was looking to how graphics drivers work in Linux, but don't except nothing good from me... It's the best source (only) for this nfo. It's at times like this when I realize how important the opensourceness is, especially for an OS. A best bet for us is to start with a simple VGA driver and VESA later, then think of the system graphic library... ...Should we port MESA? If so then should we count on GCC-CIL? I'm somehow worried if it would be reliable enough in both performance and functionality for this task... ...Or should we start our own graphics library in C#? It's a BIG engagement! But we like challenges. Don't we? ;) If so, shall we design it so that it stands for GDI+/cairo, pango and OpenGL all in one? IMHO it should be one big library. Well modularized of course, but perfectly integrated too. So we could write our widget system in OGL-like environment with support for hardware graphics, and vice-versa insert widgets, unicode text and stuff easily into multimedia applications. Oh and for media streaming, do you prefer gstreamer or phonon like solution? JK... Actually, we'll end up with a similar topic someday, probably :P > 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.. I just happened to see one of Singularity publications, here's a piece of it: <<Unlike Singularity’s segregation of SIPs on disjoint memory pages, other safe language systems have taken the approach of having processes allocate memory from a single, shared heap. Singularity’s design has several advantages. First, it reduces coupling between processes by eliminating the shared memory allocator and garbage collector and by permitting each process to allocate and reclaim its own memory using the techniques that are appropriate. The large number of existing garbage collection algorithms, and experience, suggest that no one garbage collector is appropriate for all systems or applications, so this flexibility helps achieve good system performance [17]. A shared heap and garbage collector constrain the object format and run-time system of every process that uses it. Moreover, these shared facilities are a common point of failure. Second, Singularity’s design facilitates process termination, as the system can simply reclaim entire memory pages, rather than relying on garbage collection to reclaim individual objects.>> As for the last one note also "Singularity’s segregation of SIPs on disjoint memory pages". On the other side, shared GC could be better for small devices. I think they support both though, but I'm not sure. Correct me if I'm wrong. What do you guys think of Singularity's ways of things: SIPs, channels? I'm not well conscious on all this stuff... |