Hacker News Reader

Comment by orbifold | Hacker News Reader

There was a research operating system by Microsoft https://en.wikipedia.org/wiki/Midori_(operating_system), which used a dialect of C#, with some interesting extensions specific to operating system / driver development.

View on HN

Joe Duffy has blogged about it, excellent read.

http://joeduffyblog.com/2015/11/03/blogging-about-midori/

Some past threads:

Blogging about Midori (2015) - https://news.ycombinator.com/item?id=21988694 - Jan 2020 (27 comments)

The Error Model in Midori - https://news.ycombinator.com/item?id=11054912 - Feb 2016 (41 comments)

Midori: A Tale of Three Safeties - https://news.ycombinator.com/item?id=10871222 - Jan 2016 (7 comments)

What happened to Microsoft's Midori operating system project? - https://news.ycombinator.com/item?id=10576697 - Nov 2015 (34 comments)

Blogging about Midori - https://news.ycombinator.com/item?id=10545353 - Nov 2015 (1 comment)

More details on Microsoft's new M# language - https://news.ycombinator.com/item?id=6983649 - Dec 2013 (49 comments)

Microsoft's Midori operating-system skunkworks project soldiers on - https://news.ycombinator.com/item?id=4758071 - Nov 2012 (1 comment)

Goodbye, XP. Hello, Midori - https://news.ycombinator.com/item?id=232554 - June 2008 (1 comment)

Also singularity, https://en.wikipedia.org/wiki/Singularity_(operating_system)

Also cosmos: https://www.gocosmos.org/

Aren't operating systems written in non-garbage-collecting languages?

Do OS written in C# have good performance?

Not necessarily. Lisp and Smalltalk for example were used for OS implementations in the 80s and many later examples followed.

If an OS runs on bare metal, who does the garbage collecting? Ain't this a paradox?

No, because there is no reason an OS couldn't have an integrated garbage collector. The garbage collector would have to be written in a non-garbage collected language or using a subset of the language that doesn't allocate on the GC heap, the no-runtime sample here shows that it would be possible to do one in C#. But there is no reason the rest of the OS couldn't use automatic memory management. Linux is a heavy user of refcounted data already, and there is no fundamental difference between that and other garbage collection strategies.

There's nothing inherently contradictory about running on bare metal, and being garbage collected. As long as you can manipulate memory directly, the garbage collector could potentially be implemented in the language itself. See the Boehm[1] GC as an example of a GC implemented in C for C/C++.

[1]: https://www.hboehm.info/gc/

that will need to bootstrap first, and you won't be able to use such GC code in the initialization code for the OS.

GC code using Boehm would not be suitable for device drivers nor realtime code.

I can understand where making it available for higher level systems is desirable.

I could envision the kinds of alternative GC systems that could be inbuilt given the knowledge an OS may have about a process or a sub-system etc. Alternatively, Objective C settled upon reference counting (ARC) and this is superior to GC where it counts.

Where do you envision the GC bootstrapping and how do you see it interacting with virtual memory and your malloc implementation?

> that will need to bootstrap first, and you won't be able to use such GC code in the initialization code for the OS.

It's all highly dependent on the interface between the language and its runtime. Hypothetically, your C# runtime (and by runtime, I'm using it in the same sense that Rust or C++ would use it; I'm not referring to a VM) could provide a function that allocates memory (C#-esque pseudocode):

    public static ulong New(ulong bytes)
    {
        if (gcInitialized)
        {
            return GcNew(bytes);
        }
        else
        {
            return BootstrapHeapNew(bytes);
        }
    }

Until the GC is boostrapped, all allocations are made on a heap, and either manually freed or kept around until the GC takes over deallocation.

> GC code using Boehm would not be suitable for device drivers nor realtime code.

I completely agree, I just provided it as an example of a GC implemented in the same language.

> Where do you envision the GC bootstrapping and how do you see it interacting with virtual memory and your malloc implementation?

I don't see the GC interacting with userland in this case, and instead would only be used for kernel data structures. I don't really think it's a good idea to have GC in a kernel, I only wanted to point out that low-level code and garbage collection are not mutually exclusive.

For that matter, until you bootstrap GC+heap, you could just use statically allocated memory, or even local arrays (via stackalloc). This would preclude using any reference types, but you can do plenty of things with just structs and unmanaged function pointers alone in C# (it's basically the expressive equivalent of C, but with generics thrown in).

> Alternatively, Objective C settled upon reference counting (ARC) and this is superior to GC where it counts.

ARC does nothing special other than automate [myCocoaClass retain] and [myCocoaClass release], a compromise after putting a conservative trancing GC in Objective did not work as expected, given the amount of caveats with GC unaware C code.

As such, Objective-C performance related to heap management remains unchanged.

The kernel obviously.

http://www.projectoberon.com/

Lisp machines had hardware/OS-based garbage collection ~40 years ago: https://en.m.wikipedia.org/wiki/Lisp_machine

Reply on news.ycombinator.com