Comment by adrusi | Hacker News Reader

Comment by adrusi | Hacker News Reader

A lot of these ideas seem really good. I like that all processes run in CPU ring 0 and safety is ensured by the VM. It seems like this is more flexible and allows for more easily provable safety guarantees. That said, I think javascript is the wrong way to go, and especially how they're doing it. Javascript carries with it the idea of garbage collection, which is fundamentally incompatible with hard realtime systems because it can create unpredictable pauses. What happens when a driver is communicating with a graphics card over a PCI bus or with an SSD over SATA and suddenly there's a GC pause? It might miss some bytes, and in the worst case scenario, the serial data stream will still be valid and the driver will carry on like nothing happened, returning corrupted data.

I'm somewhat confused about the concurrency model in Runtime, The frontpage says it ditches traditional preemptive multitasking in favor of an event loop, but another pages says it runs a v8 isolate on each core. I'm going to assume that this means on my machine with 8 virtual cores there would be 8 parallel event loops. An eventloop for multiplexing OS processes on the timeline is simply not appropriate for the general usecase. If any process performs a CPU-bound operation, it would block all other processes in the same v8 isolate. This system is also not very good for multicore operations, it's impossible to properly balance to load on each core, leading to poor performance. Traditional kernels can run a single thread on core A one millisecond and core B the next, but even if it's possible to send a process between isolates, it would be a lot less efficient than simply remapping the address space.

I think it would be much better use LLVM bitcode instead of javascript. Instead of JIT compilation, the Kernel compiles the program to machine code when it loads it into memory, verifying that it's not using any unauthorized constructs statically. LLVM bitcode is already being used like this by PNaCl. It offers the same security guarantees as javascript, but without the overhead associated with it.

It doesn't use threads, but programs are still preemptable. Single event loop uses multiple event queues. Every program owns its own event queue and runs in separate V8 context.

V8 supports script interruption for contexts. Engine puts interrupt guard checks into every function and every loop. So its possible to interrupt context even in a middle of infinite loop.

Yes, system doesn't solve multicore balancing problem for applications automatically. The idea is that every app can use available cores on a machine similar to a fixed size thread pool. So it can manually schedule tasks for available cores.

Whats interesting, that this thread pool could provide transparent access to computing power on other physical machines. So this should be pretty scalable.

GC pauses. Yes, this is a problem, but it shouldn't corrupt any data. I think hardware interfaces should provide some kind of error checking mechanism with the option to retry transmission. Worst case - critical parts implemented in native code.

Another idea how to deal with GC pauses is to reserve one core specifically for V8 concurrent GC tasks for every other core. Additionally this core can take care of all interrupt handlers.

> I like that all processes run in CPU ring 0 and safety is ensured by the VM. It seems like this is more flexible

This approach has a few issues which make it impractical for use by a real general purpose OS:

* it moves all work related to safety either to the dynamic compiler (not so bad), when it can statically prove that the code is safe or onto the critical path if it cannot statically prove it safe (which generally causes significant slow-downs). For example a traditional OS will use VM to isolate application memory (where the performance impact comes from the occasional TLB miss), while this sort of approach might require boundary checks to be compiled before many memory instructions

* the problems mentioned above could be mostly avoided by requiring use of a language or bytecode format designed to allow the compiler to use static checks, but then all your applications have to use it (which is what Runtime.JS does)

* it potentially allows more complex interactions between the OS/VM and the application compared to traditional system calls, which is the sort of things that often enough creates hard-to-predict side effects

> allows for more easily provable safety guarantees.

I don't know about that, hardware is normally formally verified, while software normally isn't. While hardware bugs still exist, there are far fewer than in software.

This approach tried in the past multiple times:

- Mesa

- Cedar

- Smalltalk

- Lisp based OS (Interlisp, Lisp Machines)

- Oberon and derivatives

So I think at least for home systems it could work.

One issue with using LLVM for this is compilation speed. JS engines are really tuned for compilation speed, whereas LLVM isn't (though NaCl's WIP SubZero backend may help here).

I share your concern about GC pauses.

LLVM bitcode provides no security guarantees whatsoever though. It has raw unchecked pointers. You can even cast arbitrary integer values to pointers and dereference them. In PNaCl, security is provided by the NaCl layer beneath the LLVM layer.

It's an interesting idea, to have an OS kernel with processes/etc sandboxed from each other with NaCl sandboxes instead of traditional protection mechanisms. I wonder how the overhead compares.

Reply on news.ycombinator.com