www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
The benefits and costs of writing a POSIX kernel in Go
By Thom Holwerda on 2018-10-08 23:51:05

This paper presents an evaluation of the use of a high-level language (HLL) with garbage collection to implement a monolithic POSIX-style kernel. The goal is to explore if it is reasonable to use an HLL instead of C for such kernels, by examining performance costs, implementation challenges, and programmability and safety benefits.

The paper contributes Biscuit, a kernel written in Go that implements enough of POSIX (virtual memory, mmap, TCP/IP sockets, a logging file system, poll, etc.) to execute significant applications. Biscuit makes liberal use of Go's HLL features (closures, channels, maps, interfaces, garbage collected heap allocation), which sub- jectively made programming easier. The most challenging puzzle was handling the possibility of running out of kernel heap memory; Biscuit benefited from the analyzability of Go source to address this challenge.

On a set of kernel-intensive benchmarks (including NGINX and Redis) the fraction of kernel CPU time Biscuit spends on HLL features (primarily garbage collection and thread stack expansion checks) ranges up to 13%. The longest single GC-related pause suffered by NGINX was 115 microseconds; the longest observed sum of GC delays to a complete NGINX client request was 600 microsec- onds. In experiments comparing nearly identical system call, page fault, and context switch code paths written in Go and C, the Go version was 5% to 15% slower.

Scientific papers about operating system experiments - who doesn't love them?

 Email a friend - Printer friendly - Related stories
.
Post a new comment
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-55
.
Excellent find Thom!
By Alfman on 2018-10-09 03:11:00
We often debate this very topic without having good data to talk about. This should make for good points of discussion.

Personally I've been leaning towards achieving memory safety through static language analysis rather than garbage collection, but this is very interesting none-the-less. These performance tradeoffs may be worthwhile in some security contexts.


> Should one use HLL for a new kernel?
The HLL worked well for kernel development

* Performance is paramount ⇒ use C (up to 15%)

* Minimize memory use ⇒ use C (↓ mem. budget, ↑ GC cost)

* Safety is paramount ⇒ use HLL (40 CVEs stopped)

* Performance merely important ⇒ use HLL (pay 15%, memory)



With garbage collection, additional memory usage is to be expected, but I do wonder if the performance could be improved upon with further optimization.
Permalink - Score: 5
.
Comment by The123king
By The123king on 2018-10-09 07:38:01
C is not a low level language: https://queue.acm.org/detail.cfm?...
Permalink - Score: -4
.
RE: Comment by The123king
By feamatar on 2018-10-09 10:07:24
I would suggest not to start this again.
Permalink - Score: 5
.
RE[2]: Comment by The123king
By The123king on 2018-10-09 12:29:25
Why? Is your computer a PDP11?

Mine is. It, however, isn't exactly fast...
Permalink - Score: -1
.
Fuschia?
By AndrewZ on 2018-10-09 12:44:46
What is Fuschia written in, C++?
Permalink - Score: 4
.
RE: Fuschia?
By moondevil on 2018-10-09 13:21:59
A mix of C++, Rust, Go and Dart.

The kernel process, most drivers and UI composition engine are in C++.

The TCP/IP stack, disk management utilities are in Go.

Rust is minimally used still.

The UI framework is Dart, as it makes use of Flutter.
Permalink - Score: 5
.
RE: Excellent find Thom!
By Lennie on 2018-10-09 15:46:38
The one I wonder about it: I always get the impression Rust would be a better choice than Go. Because Rust doesn't use GC, uses less memory and less CPU and is faster in a lot of cases.
Permalink - Score: 2
.
goroutines vs coroutines
By kwan_e on 2018-10-09 16:27:59
> The Go collector does most of its work during calls to
the heap allocator, spreading out this work roughly evenly
among calls. Thus goroutines see delays proportional to
the amount that they allocate;
§
8.5 presents measurements
of these delays for Biscuit.


Coroutines will be coming to C++, and so will heap elision. They both have working implementations, leading to what some call "negative overhead abstractions".
Permalink - Score: 4
.
Comment by FlyingJester
By FlyingJester on 2018-10-09 17:45:53
The one thing that smells slightly to me is that they changed the code paths in an existing C kernel to be more like what they had written in Go.

Different languages encourage and allow different operations and methodologies, and make different guarantees. I think a better comparison would be a "natural" C kernel and a "natural" Go kernel, both with similar effort put into optimization.
Permalink - Score: 3
.
RE[2]: Excellent find Thom!
By Alfman on 2018-10-09 18:12:16
Lennie,

> The one I wonder about it: I always get the impression Rust would be a better choice than Go. Because Rust doesn't use GC, uses less memory and less CPU and is faster in a lot of cases.

I think so too, but right I'd welcome development in any of them because I feel change is long overdue.

High level developers have been more adventurous with new languages like python, coffeescript, ruby, etc, but most low level systems programming hasn't embraced change. I'm just as guilty as anyone. The barrier for me is that the current tools are so well established that retooling/rewriting everything to basically get what we already have is a really hard sell. Of course security is a pro for switching, but investing in platforms with an uncertain future with rather limited support and requiring niche developer skills can be difficult to justify. For better or worse, there are efficiencies to be had by following the big crowds, regardless of if it's the best choice or not.
Permalink - Score: 3

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-55

Currently browsing at -500.
Browse at your normal score threshold.

Post a new comment
Username

Password

Title

Your comment

If you do not have an account, please use a desktop browser to create one.
LEAVE SPACES around URLs to autoparse. No more than 8,000 characters are allowed. The only HTML/UBB tags allowed are bold & italics.
Submission of a comment on OSNews implies that you have acknowledged and fully agreed with THESE TERMS.
.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?