ntfs wrote:
But the thing which I had not figured out is how they do the message passing... They say that they do it without copiing and I can't imagine any way doiing it without breaking heap integrity.
The key idea is that they use "tracking references" so that the compiler can statically determine when a block of exchange heap memory is no longer owned by a process (i.e. -- when it is sent over a channel or deallocated). Exchange heap memory is typed differently than other memory.
This paper covers the implementation details of channels.
ntfs wrote:
GC would be only fall back for nasty applications. Applications would clean memory by combination of reference counting and explicit deallocation. Reference counting cannot handle circular references (eg A points to B, B points to A), but theese circles could be explicitly broken by aplication
With explicit deallocation, it's very difficult for the compiler to ensure that there are no problems with double deletion. What's the big problem with GC anyway?
ntfs wrote:
No closed processes - you can use final when you need and it has nearly the same effect and is more flexible
I thought closed processes were the thing that makes Singularity dependable. Moving away from them brings back a lot of problems, doesn't it? What do you mean by "final" exactly?
ntfs wrote:
I am currently in my system planning to have generics implementation by erasure, but additional system can be added(might be using class loaders) to the environment and this would allow mixins(in my opinion they are not very usefull anyway).
Mixins are extremely useful! Trying to design large-scale systems without them really sucks IMO. It tends to lead to all sorts of useless containment and delegation just to keep separate concerns apart. Have you heard of
Scala? It makes mixins a very important part of the language, with some very interesting benefits.