Hacker News Reader

Comment by DblPlusUngood | Hacker News Reader

Well that was fast! I'm an author of this paper and would be happy to answer questions.

I'm not at OSDI or I would have asked there, but:

1. Your skepticism for using Rust cites [26], the PLOS paper from the same people who did [27]. They've essentially recanted, in that their PLOS talk was right after Niko's keynote, and he then talked them through how interior mutability works in Rust. Other than [26], are there other lingering concerns? I could imagine so, but it would be great to take stock.

2. You don't seem to page to disk, and do OOM shootdowns instead. If you did enable disk paging, how comically bad an idea does a tracing GC become? :D Naively, I could imagine RC-GC being less horrible, but perhaps that's my built-in (and absolutely for real) bias.

1. I wouldn't say we are skeptical of Rust, I'm sure it could be made to work well and we would love to see such a Rust kernel! I do wonder whether it would be harder to implement highly-concurrent data structures in Rust though, such as the directory cache.

2. GC performance would be basically unaffected by paging, since kernels don't page their own heaps out to disk and thus a kernel heap access would never have to wait for a disk IO. Or maybe you had something else in mind?

1. Jon sits two desks away, right? ;)

Re 2., I assumed (incorrectly, it seems) that virtual memory mappings can eventually spill to disk. If you grab 1/32 of RAM For the kernel, then you could only virtually map 16x RAM if the page tables have 512 entries. Admittedly, I took my OS class in the previous millennium, so I might be out of date here...

For the ”C kernel vs go kernel” benchmarks, the paper writes ”The benchmarks allocate no heap memory in steady-state, so Biscuit’s garbage collector is not invoked.”.

Is that a fair way to make this comparison?

Also, ”This results in heap bounds of less than 500kB for all system calls but rename and fork (1MB and 641kB, respectively).”

How does that compare to the C-based kernel?

Finally, how does this system hold up after days of uptime?

Concerning your first question, that experiment is not intended to measure the cost of GC, which can be made small by trading memory. The point of this experiment is to measure the unavoidable costs of the language.

I would think that measures less costs of the language than costs caused by differences in compiler quality/focus.

Or are there go features that make it inherently slower than C for kernel programming, even when ignoring GC?

Non sequitur, but is Cody Cutler (you?) related to Dave Cutler, the designer of VMS and Windows NT? Maybe OS programming runs in the family :)

Hah, I am Cody and I'm not related to Dave Cutler (as far as I know!).

Is the code on GitHub?

As it can be seen on one of the last slides, it is on GitHub[0].

[0] https://github.com/mit-pdos/biscuit

Any plans to borrow code from gVisor to attain full Linux compatibility?

interesting 'x' commit messages ..

Maybe sometimes the mental effort of writing a commit message just isn't worth it.

At work, I try to be a good boy and write proper commit messages, always.

On personal projects, I often just use "." or something equally meaningless. Sometimes I can't be bothered explaining myself, and on a personal project nobody is going to be burned by it but me.

Well... except in this case they referenced the repo in a paper, so of course folks are going to have a look, fork it, play with it, etc.

A quick scan suggests these commits are comment changes only.

The recent ones are. There are a few further back in history which are substantive changes. Any thoughts on what this change did:

https://github.com/mit-pdos/biscuit/commit/b262c40b1baf1fb1a...

Reply on news.ycombinator.com