4 ms·

Isn't Nim GCed? How are you going to build a kernel like that?

by pkulak 12y ago

chroem- 12y ago
GC in Nim is highly configurable: you can pause GC or even delay it indefinitely. Plus there's lots of tweaks you can make to how GC treats your code using Nim's pragma system. And no, the standard library does not rely on GC like in D.
- pcwalton 12y ago
  My issue with this approach is that it seems inherently racy in multithreaded programs. Nim gets around that issue by having a per-thread GC and segfaulting if you send pointers to other threads (unless you use the Boehm GC, last I checked)—your only backup seems to be manual memory management—but I don't see that as a scalable approach for large-scale software with dozens or hundreds of threads. (Not to mention that not having a thread-safe GC neglects a major benefit of a GC for lock-free data structures; having to use hazard pointers if you're a GC'd language seems like a shame.)
- ptx 12y ago
  > And no, the standard library does not rely on GC like in D. Does this mean that all of the standard library is written using manual memory management? Wouldn't this slow down its development and expose it to all the same reliability and security problems C has?
- gfasdgsfd 12y ago
  > And no, the standard library does not rely on GC like in D. This isn't correct, it relies heavily on GC.
falcolas 12y ago
The presence or lack of a GC has nothing to do with the Kernel. The Kernel is simply another program, with specific requirements and limitations. So long as your language allows you to write and call raw assembly, you can write a Kernel. It's worth remembering that Rust has a form of GC as well - it uses a reference counting collection mechanism which is executed at scope boundaries instead of as a separate thread or co-routine. This doesn't prevent writing Kernels or userspace applications in Rust.
- jblow 12y ago
  Kernels tend to want to be very specific about how memory is being used. GCs cause the opposite situation. i.e. these "specific requirements and limitations" you mention have a LOT to do with memory.
  - msandford 12y ago
    Kernels need to be very specific about how other program's memory is being used. And they try and keep their own memory usage low (and predictable) because that's easier to understand and debug and doesn't waste system resources. Just because there's a GC on the kernel's memory doesn't mean that the GC is somehow now working on all the process' memory that the kernel is running. That's not how the kernel works. The page table just holds a bunch of information about which processes are using which pages, garbage collecting a particular page table entry because the entry wasn't being used anymore wouldn't cause the memory which the entry was pointing to to suddenly be destroyed. And if the page table entry somehow gets to the point where it could be garbage collected that would mean that nothing is referencing it anymore, which would (in a properly written kernel free of bugs!) mean that the process isn't using the memory anymore, so there's no harm done.
  - falcolas 12y ago
    Yes, locations in memory, not the kernel's working memory space. i.e. so long as you can have your program loaded after a certain point, write to, and read from, specific locations in memory, you're fine. How the kernel manages its own memory is up to it (for example, one of the tasks which is required to bootstrap into C is establishing a stack so you can call a C method). EDIT: Real life example of a GC'ed kernel: https://en.wikipedia.org/wiki/JavaOS https://en.wikipedia.org/wiki/JavaOS
- vertex-four 12y ago
  I'll note that Rust's reference counting system is not a full garbage collector - it can't detect cycles. As a result, if you create cycles, you leak memory. You don't want a garbage collector in a kernel, because there's a lot of code that needs to run in soft realtime - aside from timekeeping, there's lots of hardware that'll enter a failure mode or drop data if you don't respond to it in time.
4ad 12y ago
The idea that you can't have a GC when building a kernel is a myth: http://en.wikipedia.org/wiki/Singularity_(operating_system) http://en.wikipedia.org/wiki/Singularity_(operating_system) http://en.wikipedia.org/wiki/Oberon_(operating_system) http://en.wikipedia.org/wiki/Oberon_(operating_system)

Isn't Nim GCed? How are you going to build a kernel like that?

by pkulak 12y ago

Isn't Nim GCed? How are you going to build a kernel like that?

GC in Nim is highly configurable: you can pause GC or even delay it indefinitely. Plus there's lots of tweaks you can make to how GC treats your code using Nim's pragma system. And no, the standard library does not rely on GC like in D.

pcwalton 12y ago
My issue with this approach is that it seems inherently racy in multithreaded programs. Nim gets around that issue by having a per-thread GC and segfaulting if you send pointers to other threads (unless you use the Boehm GC, last I checked)—your only backup seems to be manual memory management—but I don't see that as a scalable approach for large-scale software with dozens or hundreds of threads. (Not to mention that not having a thread-safe GC neglects a major benefit of a GC for lock-free data structures; having to use hazard pointers if you're a GC'd language seems like a shame.)
ptx 12y ago
> And no, the standard library does not rely on GC like in D. Does this mean that all of the standard library is written using manual memory management? Wouldn't this slow down its development and expose it to all the same reliability and security problems C has?
gfasdgsfd 12y ago
> And no, the standard library does not rely on GC like in D. This isn't correct, it relies heavily on GC.

falcolas 12y ago

The presence or lack of a GC has nothing to do with the Kernel. The Kernel is simply another program, with specific requirements and limitations. So long as your language allows you to write and call raw assembly, you can write a Kernel. It's worth remembering that Rust has a form of GC as well - it uses a reference counting collection mechanism which is executed at scope boundaries instead of as a separate thread or co-routine. This doesn't prevent writing Kernels or userspace applications in Rust.

jblow 12y ago
Kernels tend to want to be very specific about how memory is being used. GCs cause the opposite situation. i.e. these "specific requirements and limitations" you mention have a LOT to do with memory.
- msandford 12y ago
  Kernels need to be very specific about how other program's memory is being used. And they try and keep their own memory usage low (and predictable) because that's easier to understand and debug and doesn't waste system resources. Just because there's a GC on the kernel's memory doesn't mean that the GC is somehow now working on all the process' memory that the kernel is running. That's not how the kernel works. The page table just holds a bunch of information about which processes are using which pages, garbage collecting a particular page table entry because the entry wasn't being used anymore wouldn't cause the memory which the entry was pointing to to suddenly be destroyed. And if the page table entry somehow gets to the point where it could be garbage collected that would mean that nothing is referencing it anymore, which would (in a properly written kernel free of bugs!) mean that the process isn't using the memory anymore, so there's no harm done.
- falcolas 12y ago
  Yes, locations in memory, not the kernel's working memory space. i.e. so long as you can have your program loaded after a certain point, write to, and read from, specific locations in memory, you're fine. How the kernel manages its own memory is up to it (for example, one of the tasks which is required to bootstrap into C is establishing a stack so you can call a C method). EDIT: Real life example of a GC'ed kernel: https://en.wikipedia.org/wiki/JavaOS https://en.wikipedia.org/wiki/JavaOS
vertex-four 12y ago
I'll note that Rust's reference counting system is not a full garbage collector - it can't detect cycles. As a result, if you create cycles, you leak memory. You don't want a garbage collector in a kernel, because there's a lot of code that needs to run in soft realtime - aside from timekeeping, there's lots of hardware that'll enter a failure mode or drop data if you don't respond to it in time.

4ad 12y ago

The idea that you can't have a GC when building a kernel is a myth: http://en.wikipedia.org/wiki/Singularity_(operating_system) http://en.wikipedia.org/wiki/Singularity_(operating_system) http://en.wikipedia.org/wiki/Oberon_(operating_system) http://en.wikipedia.org/wiki/Oberon_(operating_system)