3 ms·

As long as they don't write the thing in C ...

by inoop 16y ago

marshray 16y ago
What would you write it in?
- stcredzero 16y ago
  Go. Maybe LuaJIT with some additions to the parser to allow optional Static typing. Smalltalk with an advanced JIT VM and parse/compile time type enforcement ala Strongtalk. Scheme.
  - Animus7 16y ago
    There's a big difference between an OS and a VM, and they accomplish different things. Go might be feasible, but forcing system-wide GC at random times for the entire system? GC is very hard to make concurrent and a single random-alloc GC'd memory space can't possibly scale to thousands of cores.
    - marshray 16y ago
      I think the problem is deeper than just concurrency and preventing GC pauses. Since a kernel is something that is expected to run forever, it can't afford to leak anything over the long term. For most GCs, collecting that last little bit of garbage (in deterministic time) requires O(committed address space) memory bandwidth. A full-copy style GC may take O(object memory), which could be an improvement. Now that memory and applications are routinely many gigabytes, this is a big deal. It's hard enough for an ecommerce web server to maintain responsiveness, I couldn't imagine trying to respond to hardware IO interrupts in real time while running a collector like that.
    - masklinn 16y ago
      > Go might be feasible, but forcing system-wide GC at random times for the entire system? GC is very hard to make concurrent and a single random-alloc GC'd memory space can't possibly scale to thousands of cores. Erlang (and its way) is a much better fit there, I think it'd be a delightful apps language: the GC runs at the (erlang) process level, each process has its own heap, so even though the GC is a vanilla generational GC by the magic of the Erlang VM it turns into a highly concurrent pauseless GC (only needs to pause a single Erlang process at a time, and you generally have tens of thousands chugging along).
    - stcredzero 16y ago
      There's a big difference between an OS and a VM, and they accomplish different things. Not so much as you might think. Both Smalltalk and Lisp were OSes early on. If you dig around in some early Smalltalk images, you'll find the 4 stubs for "put the drive head down" "pick the drive head up" "move the drive head out" "move the drive head in."
- Animus7 16y ago
  { write it in javascript } In all seriousness, when you have to support hardware controllers whose only interface to the CPU is a memory block or I/O instructions, what other choice do you have besides C? I guess you have C++...
  - nivertech 16y ago
    *Assembler *Forth *Any language which allows inline assembly. *Any statically typed language compiled to C: Haskell, Ocaml, Go, etc.
    - rbanffy 16y ago
      *Any language that can reference memory locations directly.
  - masklinn 16y ago
    Any language in which you built support for that kind of manipulations? I mean it's not like C magically gets features.
- inoop 16y ago
  The problem with C is that it's not memory safe. Therefore you need hardware hacks (MMU) to separate processes. If you use a memory safe language you lose the ability to do pointer arithmetic (and the speed hacks that come with it), but you don't need to remap the page table every time you switch between processes. This makes threads and processes pretty much the same thing. Code injection is impossible in a memory-safe language, which helps with security (I'm talking about buffer overflows here, not SQL injecion, XSS etc). Using a higher-level language can also help with many other things, for example integrated garbage collection, built-in serialization and process migration, intelligent message passing (pass objects around rather than bytes), etc. A good example of an implementation of these ideas is Singularity (http://research.microsoft.com/en-us/projects/singularity/ http://research.microsoft.com/en-us/projects/singularity/), which is written in a superset of C#.
  - jedbrown 16y ago
    VM is also useful to handle fragmentation and to map parts of a large "array" to different NUMA nodes (so that it can be accessed by several threads without overloading a single memory channel). In a multi-process system, if you get rid of VM, you'll be pretty much obliged to have kernel-level relocating GC or to make array indexing involve software table lookup. I keep my TLB, thank you.
  - cynicalkane 16y ago
    Therefore you need hardware hacks (MMU) to separate processes I cannot apprehend the confusion of ideas that would lead you to believe this is caused by C. It's assembly, not C, that runs on your machine, and assembly is not memory safe. Microsoft's Singularity runs managed code, so there's a software layer providing memory protection. An operating system is not defined by its preferred programming language.
    - inoop 16y ago
      "I cannot apprehend the confusion of ideas that would lead you to believe this is caused by C. It's assembly, not C, that runs on your machine, and assembly is not memory safe" There is no confusion of ideas, but I like the Babbage reference :) In Singularity the code is compiled first to CIL, then to x86, x64, or ARM by an AOT (ahead-of-time) compiler. Now here's the thing: the OS loader does not load Assembly code, it loads CIL code, which it then compiles further down to Assembly. Since CIL is verifiably memory safe (like Java bytecode), and assuming the AOT compiler is not buggy, the OS is memory safe. Hence no need for MMU/MPU to do memory protection. So even though you're right that Assembly is not memory safe, the final compiler stage (in this case CIL can be seen as an intermediary language) is implemented in the OS (the loader), and the OS will reject any non-memory safe code. No code that can write outside array boundaries, violates type safety, and attempts pointer arithmetic will be allowed to execute. So no, Singularity does not provide a software layer for memory protection, it's purely an (intermediary) language feature.
- pcwalton 16y ago
  Rust :) Compiled, concurrent, and memory-safe, with no global GC. (Full disclosure: I work on Rust.)
- vilya 16y ago
  BitC maybe (if it ever reaches a stable 1.0 release): http://www.bitc-lang.org/ http://www.bitc-lang.org/ Cyclone would be another candidate: http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/ Cilk would be another interesting option, with its built-in support for concurrency: http://software.intel.com/en-us/articles/intel-cilk-plus/ http://software.intel.com/en-us/articles/intel-cilk-plus/
cletus 16y ago
Yeah because Linux has worked out so badly...
- m0th87 16y ago
  It's a research project. User uptake is not a (major) factor.

As long as they don't write the thing in C ...

by inoop 16y ago

As long as they don't write the thing in C ...

marshray 16y ago

What would you write it in?

stcredzero 16y ago
Go. Maybe LuaJIT with some additions to the parser to allow optional Static typing. Smalltalk with an advanced JIT VM and parse/compile time type enforcement ala Strongtalk. Scheme.
- Animus7 16y ago
  There's a big difference between an OS and a VM, and they accomplish different things. Go might be feasible, but forcing system-wide GC at random times for the entire system? GC is very hard to make concurrent and a single random-alloc GC'd memory space can't possibly scale to thousands of cores.
  - marshray 16y ago
    I think the problem is deeper than just concurrency and preventing GC pauses. Since a kernel is something that is expected to run forever, it can't afford to leak anything over the long term. For most GCs, collecting that last little bit of garbage (in deterministic time) requires O(committed address space) memory bandwidth. A full-copy style GC may take O(object memory), which could be an improvement. Now that memory and applications are routinely many gigabytes, this is a big deal. It's hard enough for an ecommerce web server to maintain responsiveness, I couldn't imagine trying to respond to hardware IO interrupts in real time while running a collector like that.
  - masklinn 16y ago
    > Go might be feasible, but forcing system-wide GC at random times for the entire system? GC is very hard to make concurrent and a single random-alloc GC'd memory space can't possibly scale to thousands of cores. Erlang (and its way) is a much better fit there, I think it'd be a delightful apps language: the GC runs at the (erlang) process level, each process has its own heap, so even though the GC is a vanilla generational GC by the magic of the Erlang VM it turns into a highly concurrent pauseless GC (only needs to pause a single Erlang process at a time, and you generally have tens of thousands chugging along).
  - stcredzero 16y ago
    There's a big difference between an OS and a VM, and they accomplish different things. Not so much as you might think. Both Smalltalk and Lisp were OSes early on. If you dig around in some early Smalltalk images, you'll find the 4 stubs for "put the drive head down" "pick the drive head up" "move the drive head out" "move the drive head in."
Animus7 16y ago
{ write it in javascript } In all seriousness, when you have to support hardware controllers whose only interface to the CPU is a memory block or I/O instructions, what other choice do you have besides C? I guess you have C++...
- nivertech 16y ago
  *Assembler *Forth *Any language which allows inline assembly. *Any statically typed language compiled to C: Haskell, Ocaml, Go, etc.
  - rbanffy 16y ago
    *Any language that can reference memory locations directly.
- masklinn 16y ago
  Any language in which you built support for that kind of manipulations? I mean it's not like C magically gets features.
inoop 16y ago
The problem with C is that it's not memory safe. Therefore you need hardware hacks (MMU) to separate processes. If you use a memory safe language you lose the ability to do pointer arithmetic (and the speed hacks that come with it), but you don't need to remap the page table every time you switch between processes. This makes threads and processes pretty much the same thing. Code injection is impossible in a memory-safe language, which helps with security (I'm talking about buffer overflows here, not SQL injecion, XSS etc). Using a higher-level language can also help with many other things, for example integrated garbage collection, built-in serialization and process migration, intelligent message passing (pass objects around rather than bytes), etc. A good example of an implementation of these ideas is Singularity (http://research.microsoft.com/en-us/projects/singularity/ http://research.microsoft.com/en-us/projects/singularity/), which is written in a superset of C#.
- jedbrown 16y ago
  VM is also useful to handle fragmentation and to map parts of a large "array" to different NUMA nodes (so that it can be accessed by several threads without overloading a single memory channel). In a multi-process system, if you get rid of VM, you'll be pretty much obliged to have kernel-level relocating GC or to make array indexing involve software table lookup. I keep my TLB, thank you.
- cynicalkane 16y ago
  Therefore you need hardware hacks (MMU) to separate processes I cannot apprehend the confusion of ideas that would lead you to believe this is caused by C. It's assembly, not C, that runs on your machine, and assembly is not memory safe. Microsoft's Singularity runs managed code, so there's a software layer providing memory protection. An operating system is not defined by its preferred programming language.
  - inoop 16y ago
    "I cannot apprehend the confusion of ideas that would lead you to believe this is caused by C. It's assembly, not C, that runs on your machine, and assembly is not memory safe" There is no confusion of ideas, but I like the Babbage reference :) In Singularity the code is compiled first to CIL, then to x86, x64, or ARM by an AOT (ahead-of-time) compiler. Now here's the thing: the OS loader does not load Assembly code, it loads CIL code, which it then compiles further down to Assembly. Since CIL is verifiably memory safe (like Java bytecode), and assuming the AOT compiler is not buggy, the OS is memory safe. Hence no need for MMU/MPU to do memory protection. So even though you're right that Assembly is not memory safe, the final compiler stage (in this case CIL can be seen as an intermediary language) is implemented in the OS (the loader), and the OS will reject any non-memory safe code. No code that can write outside array boundaries, violates type safety, and attempts pointer arithmetic will be allowed to execute. So no, Singularity does not provide a software layer for memory protection, it's purely an (intermediary) language feature.
pcwalton 16y ago
Rust :) Compiled, concurrent, and memory-safe, with no global GC. (Full disclosure: I work on Rust.)
vilya 16y ago
BitC maybe (if it ever reaches a stable 1.0 release): http://www.bitc-lang.org/ http://www.bitc-lang.org/ Cyclone would be another candidate: http://cyclone.thelanguage.org/ http://cyclone.thelanguage.org/ Cilk would be another interesting option, with its built-in support for concurrency: http://software.intel.com/en-us/articles/intel-cilk-plus/ http://software.intel.com/en-us/articles/intel-cilk-plus/

cletus 16y ago

Yeah because Linux has worked out so badly...

m0th87 16y ago
It's a research project. User uptake is not a (major) factor.