[SharpOS Developers] IRCMeeting

[Sander v. R. <san...@gm...>]

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..