Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An immutable operating system

augustl.com

Post reply on HN
Print view View original

81–90 of 153 posts

Re: An immutable operating system

#81

Post by imsofuture »

cfallin wrote: post #80
agumonkey wrote: post #35

Earlier quoted context omitted.

I see a number of projects sharing similar traits: - DVCS - btrfs,zfs - rethinkdb - persistent datastructures (cons cells, fp trees) - nix package management, virtualenv, containers - react/pedestal (pushing ux delta upgrades)

Mutability/immutability goes pretty deep philosophically... all of those projects are basically built on persistent data structures, but persistent data structures can be seen as just one type of "making time explicit". In other words, with mutability, a variable (or data structure) takes different values at different times, while with immutability, you can still have time but you name each version through time expli…

As an aside: I'm pretty mind blown that I've never once considered immutability as "making time explicit". That's an extremely apt comparison.

Re: An immutable operating system

#82

Post by [deleted] »

lisper wrote: post #49
augustl wrote: post #19

Earlier quoted context omitted.

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.

Doesn't matter. In an immutable model, the old copy is guaranteed not to change, so you can safely copy it non-atomically. (That's one of the big benefits of immutability.)

[deleted]

Re: An immutable operating system

#83

Post by stcredzero »

vinkelhake wrote: post #36
stcredzero wrote: post #10

Earlier quoted context omitted.

As I mentioned elsewhere, such an OS could have important performance benefits. GC could be made to be incremental at a fundamentally new level. In fact, incremental GC could be nothing more than a series of defrag copies that proceed at a rate just faster than new object creation. Such a system would rock for writing real-time systems.

Important performance benefits compared to what? Systems that are very performance sensitive typically don't use garbage collectors to begin with. They instead rely on techniques to avoid generating much garbage in the first place.

You're making my point for me here. This kind of technology might make it possible to write even more performant soft real-time systems but still have the productivity benefits of GC.

Re: An immutable operating system

#84

Post by timclassic »

I haven't written any Clojure, but I have written a good bit of Erlang. My understanding of the Erlang Virtual Machine tells me that it solves a lot of the problems you describe regarding immutable data. For example, per-process garbage collection due to immutability, message passing via copying data, etc.

I think you would be well-served to experiment with and learn some Erlang to help inform your design. In fact, Erlang often feels to me like an operating system due to the independence of processes (and the multitude of tools built on top of it, but that's not directly relevant here). I've often dreamt of an Erlang Machine like the Lisp Machines of the past.

As an aside, Erlang's primary goal is fault-tolerance. It's other properties, such as immutable data, message passing, and functional properties were all design decisions made to achieve this goal. My point is that your OS could be very well suited to fault-tolerant systems.

Re: An immutable operating system

#85

Post by cwzwarich »

sillysaurus2 wrote: post #76
procrastitron wrote: post #54

I wrote an operating system in a purely functional dialect of Lisp; http://losak.sf.net There are a few things I learned in the process that I think are relevant here: 1. Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. If you use reference counting, then there is a lazy variant…

Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. Is the assumption that mark and sweep is slower than real-time memory management? It's actually been proven false, e.g. the .NET CLR runs faster than native C code in certain situations. If you use reference counting, then there is…

Tracing garbage collection has better throughput than reference counting, but reference counting has lower and more predictable latency.

If you were actually going to try do tracing GC on the operating system level, you would probably have to use one of the more involved GC algorithms that require kernel support like Azul's C4 collector.

Re: An immutable operating system

#86

Post by stcredzero »

barrkel wrote: post #29
RyanZAG wrote: post #14

Earlier quoted context omitted.

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…

Generational GC usually depends on write barriers to detect creation of references to newer generations inside older generations. Immutability prevents the mutation of older generations, so no new references can occur. So I expect generational GC to be easier to implement. I wouldn't expect it to be faster or slower though, because programs will need to be written differently to cope with the limitations on mutabilit…

In the case of Clojure, log is log base 32, so it's close enough to O(1) as to make no difference in most circumstances.

Re: An immutable operating system

#87

Post by kibwen »

augustl wrote: post #78
Tyr42 wrote: post #67

Earlier quoted context omitted.

Rust?

Have considered writing the entire kernel in Rust. Haven't considered using it for the system language, will defenitely consider that.

If you do end up using Rust for any part of this project, we'd love to hear about the experience on our mailing list:

https://mail.mozilla.org/listinfo/rust-dev

Re: An immutable operating system

#88

Post by stcredzero »

lisper wrote: post #49
augustl wrote: post #19

Earlier quoted context omitted.

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.

Doesn't matter. In an immutable model, the old copy is guaranteed not to change, so you can safely copy it non-atomically. (That's one of the big benefits of immutability.)

Which makes really good incremental collection much easier to write

Re: An immutable operating system

#89

Post by gohrt »

augustl wrote: post #57
procrastitron wrote: post #54

I wrote an operating system in a purely functional dialect of Lisp; http://losak.sf.net There are a few things I learned in the process that I think are relevant here: 1. Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. If you use reference counting, then there is a lazy variant…

Author here. The language is the part I also dread the most, and is also the part that will be the least unique and the least interesting to "re-invent".. I'll look into finding an existing language that runs on bare metal and that has (or supports) immutable values.

Haskell

Re: An immutable operating system

#90

Post by stcredzero »

masklinn wrote: post #39
stcredzero wrote: post #7

A 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…

> This might actually have significant performance benefits. Not really. On the other hand, it makes the implementation of GCs much simpler. (immutability semantics also tends to make memory churn much higher, so what little gain you get from a simpler implementation is often lost in the GC having to do more work) Also, it's not like these things are unstudied FFS.

It's not just GC, but virtually pause-less GC that is the possible benefit. Yes, these things are studied, but I would challenge you to find a free high level language implementation with GC suitable for soft real time. Right now, I know of Erlang, which isn't the fastest language and running Clojure on the proprietary Azul VM.
Post reply on HN