Just curious have you started looking into some of the LISP machines of old? You might be able to get a head start by studying their structure (and of course their decisions):
An immutable operating system
11–20 of 153 posts
Re: An immutable operating system
#12An operating system whose main goal is not performance is forever going to be a toy of professors. Linux is a mess compared to the beautiful code that would comprise this OS, but it's a mess that runs fast on real hardware and let's people get stuff done. That matters.
Sometimes 'toy of professors' (research) is the point.
Not everything has to run a social network and not everyone is working on a twitter clone.
Re: An immutable operating system
#13A garbage collector that knows that all values are immutable will be rather interesting, I think. Typically, a garbage collector will stop the world (i.e. halt execution) to do heap defragmentation of the old generation. When all values are immutable, though, you can defragment the heap by copying a value to another fragment and just swap the internal pointer to the value. This might actually have significant perform…
"When all values are immutable, though, you can defragment the heap by copying a value to another fragment and just swap the internal pointer to the value."
Wouldn't that turn shared objects into not-shared objects? Theoretically, that doesn't make a difference in a system without mutable data (assuming you leave out 'identity check', too), but in practice, it likely will blow up memory usage tremendously.
Edit: I think the way around this is to replace the moved object with a "this object moved" object. The trick, then, will be to know when it is OK to discard that "this object moved" object. That probably is the case after a full heap scan.
Re: An immutable operating system
#14A garbage collector that knows that all values are immutable will be rather interesting, I think. Typically, a garbage collector will stop the world (i.e. halt execution) to do heap defragmentation of the old generation. When all values are immutable, though, you can defragment the heap by copying a value to another fragment and just swap the internal pointer to the value. This might actually have significant perform…
I don't see how immutability makes much difference to garbage collection. Garbage collectors don't look at the value inside memory they are collecting, only whether something live is still retaining that part of memory. Whether the value is mutable or immutable has absolutely no bearing on the performance or logic of the GC. Either something is still using the memory, or it is free to collect.
Also you've just described existing GC systems - The Java G1 collector is very similar that (it's a lot more complicated though).
Re: An immutable operating system
#15An operating system whose main goal is not performance is forever going to be a toy of professors. Linux is a mess compared to the beautiful code that would comprise this OS, but it's a mess that runs fast on real hardware and let's people get stuff done. That matters.
Finding new ~structures is important, see the issues with X vs Wayland. By re-ordering things you get far better performance even on limited systems (raspberry pi for instance). Sure you lose other properties but that's part of the compromise. I'd love to see a similar effect on the whole system by going immutable first. With added that it could give a smaller system, easier to understand, secure, change.
Re: An immutable operating system
#16An operating system whose main goal is not performance is forever going to be a toy of professors. Linux is a mess compared to the beautiful code that would comprise this OS, but it's a mess that runs fast on real hardware and let's people get stuff done. That matters.
On the surface, you wouldn't think immutable data structures would offer any significant performance gains. But there are a lot of cool techniques and unforeseen consequences that emerge.
The clojure library "om" is able to use reference equality (instead of a deep comparison) to check for diffs. This results in a 2x or 3x performance gain over mutable data structures.
So I agree with you, this will likely just be a toy OS. But if his design demonstrate huge advantages, the ideas could be adopted by mainstream operating systems.
Re: An immutable operating system
#17Just curious have you started looking into some of the LISP machines of old? You might be able to get a head start by studying their structure (and of course their decisions): https://en.wikipedia.org/wiki/Lisp_machine
There are definitely interesting things there, but fwiw Lisp machines weren't based on immutable data structures. Common Lisp in general has an ethos of being multiparadigm and using imperative updates whenever convenient or performant. Functional constructs are probably used more than in C-like languages, but not exclusively, and are probably a minority approach in "production" Common Lisp. That's one place where Clojure differs quite a bit from CL; it sort of combines the "Schemey" preference for functional style, non-destructive functions, recursion, etc., with the CL ambition of a "batteries included" library and industrial-strength tooling.
However if you look at the first-order similarity as not being immutable data structures, but instead the idea of an OS entirely built within a managed runtime, the Lisp Machines and Microsoft's Singularity OS (C#) are two interesting examples.
Re: An immutable operating system
#18An operating system whose main goal is not performance is forever going to be a toy of professors. Linux is a mess compared to the beautiful code that would comprise this OS, but it's a mess that runs fast on real hardware and let's people get stuff done. That matters.
On the surface, you wouldn't think immutable data structures would offer any significant performance gains. But there are a lot of cool techniques and unforeseen consequences that emerge. The clojure library "om" is able to use reference equality (instead of a deep comparison) to check for diffs. This results in a 2x or 3x performance gain over mutable data structures. So I agree with you, this will likely just be a…
Forgot to source my info on the "om" library. http://www.infoq.com/news/2014/01/om-react
Re: An immutable operating system
#19A garbage collector that knows that all values are immutable will be rather interesting, I think. Typically, a garbage collector will stop the world (i.e. halt execution) to do heap defragmentation of the old generation. When all values are immutable, though, you can defragment the heap by copying a value to another fragment and just swap the internal pointer to the value. This might actually have significant perform…
I don't see how immutability makes much difference to garbage collection. Garbage collectors don't look at the value inside memory they are collecting, only whether something live is still retaining that part of memory. Whether the value is mutable or immutable has absolutely no bearing on the performance or logic of the GC. Either something is still using the memory, or it is free to collect. Also you've just descri…
The actual GC of freeing memory is indeed possible (and common) without stop the world. Heap defrag is another story, though. This involves moving objects to different locations in memory, and if the memory is mutable, measures like stop the world is required since multi-byte move is not atomic.
Re: An immutable operating system
#20Just curious have you started looking into some of the LISP machines of old? You might be able to get a head start by studying their structure (and of course their decisions): https://en.wikipedia.org/wiki/Lisp_machine
There are definitely interesting things there, but fwiw Lisp machines weren't based on immutable data structures. Common Lisp in general has an ethos of being multiparadigm and using imperative updates whenever convenient or performant. Functional constructs are probably used more than in C-like languages, but not exclusively, and are probably a minority approach in "production" Common Lisp. That's one place where Cl…
Op here, thanks to both of you :) I would very much like to expand prior art to more than just Linux and Clojure.