On Thu, Sep 13, 2018 at 10:34 PM Andrew Warkentin <andreww591@gmail.com> wrote:
On 9/13/18, John <john.r.moser@gmail.com> wrote:
>
> I'm surveying the field at the moment and looking at all the advances made
> in computer software—security, managed language runtimes, hypervisors,
> real-time OS—and trying to project the possibilities for a next-generation
> operating system.  There's enough divergence that a rewrite from scratch
> might make sense; and besides, I've drawn up a method for getting a
> self-hosting CLR running with only anonymous memory allocation and VFS file
> page mapping, along with a method of getting the CLR to self-host and
> getting it up and running before an actual OS kernel.
>

It seems like things might be moving away from managed code somewhat.
Safer native code languages like Rust have been starting to become
more popular in recent years. I think safer native code is a better
approach than Java/.NET-style manged code, since there's no
performance penalty and the runtime is just a library rather than a
more complex VM (which is often written in an unsafe native code
language, leaving more attack surface than a system in which
everything security-critical is written in a safer language). I'm

Eh, I happen to like C# as a language.

Also, there's not necessarily a performance penalty in CLR because it's JIT to native code.  The CLR isn't actually interpreting bytecode as it goes; rather it's compiling the program, storing that compiled program in memory, and entering the compiled native code.  The outcome is the same as compiling a language to a native machine language.

I designed a way for the CLR to self-host:  it'd be written in C#, and running on itself.  This is still theoretical, of course.

At its heart, the CLR is just converting bytecode to machine code.  The thing people call a "VM" is basically a compiler and a garbage collector.
 
taking the safer native code approach in the OS that I'm writing (a
Rust-based next-generation Unix-like OS that will somewhat resemble
QNX and Plan 9; <https://gitlab.com/uxrt>).

_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers