4 ms·

If an OS runs on bare metal, who does the garbage collecting? Ain't this a paradox?

messe 5y ago
There's nothing inherently contradictory about running on bare metal, and being garbage collected. As long as you can manipulate memory directly, the garbage collector could potentially be implemented in the language itself. See the Boehm[1] GC as an example of a GC implemented in C for C/C++. [1]: https://www.hboehm.info/gc/ https://www.hboehm.info/gc/
- deleted 5y ago
  [deleted]
- hootbootscoot 5y ago
  that will need to bootstrap first, and you won't be able to use such GC code in the initialization code for the OS. GC code using Boehm would not be suitable for device drivers nor realtime code. I can understand where making it available for higher level systems is desirable. I could envision the kinds of alternative GC systems that could be inbuilt given the knowledge an OS may have about a process or a sub-system etc. Alternatively, Objective C settled upon reference counting (ARC) and this is superior to GC where it counts. Where do you envision the GC bootstrapping and how do you see it interacting with virtual memory and your malloc implementation?
  - messe 5y ago
    > that will need to bootstrap first, and you won't be able to use such GC code in the initialization code for the OS. It's all highly dependent on the interface between the language and its runtime. Hypothetically, your C# runtime (and by runtime, I'm using it in the same sense that Rust or C++ would use it; I'm not referring to a VM) could provide a function that allocates memory (C#-esque pseudocode): public static ulong New(ulong bytes) { if (gcInitialized) { return GcNew(bytes); } else { return BootstrapHeapNew(bytes); } } Until the GC is boostrapped, all allocations are made on a heap, and either manually freed or kept around until the GC takes over deallocation. > GC code using Boehm would not be suitable for device drivers nor realtime code. I completely agree, I just provided it as an example of a GC implemented in the same language. > Where do you envision the GC bootstrapping and how do you see it interacting with virtual memory and your malloc implementation? I don't see the GC interacting with userland in this case, and instead would only be used for kernel data structures. I don't really think it's a good idea to have GC in a kernel, I only wanted to point out that low-level code and garbage collection are not mutually exclusive.
    - int_19h 5y ago
      For that matter, until you bootstrap GC+heap, you could just use statically allocated memory, or even local arrays (via stackalloc). This would preclude using any reference types, but you can do plenty of things with just structs and unmanaged function pointers alone in C# (it's basically the expressive equivalent of C, but with generics thrown in).
  - pjmlp 5y ago
    > Alternatively, Objective C settled upon reference counting (ARC) and this is superior to GC where it counts. ARC does nothing special other than automate [myCocoaClass retain] and [myCocoaClass release], a compromise after putting a conservative trancing GC in Objective did not work as expected, given the amount of caveats with GC unaware C code. As such, Objective-C performance related to heap management remains unchanged.
pjmlp 5y ago
The kernel obviously. http://www.projectoberon.com/ http://www.projectoberon.com/
kryptiskt 5y ago
No, because there is no reason an OS couldn't have an integrated garbage collector. The garbage collector would have to be written in a non-garbage collected language or using a subset of the language that doesn't allocate on the GC heap, the no-runtime sample here shows that it would be possible to do one in C#. But there is no reason the rest of the OS couldn't use automatic memory management. Linux is a heavy user of refcounted data already, and there is no fundamental difference between that and other garbage collection strategies.
profquail 5y ago
Lisp machines had hardware/OS-based garbage collection ~40 years ago: https://en.m.wikipedia.org/wiki/Lisp_machine https://en.m.wikipedia.org/wiki/Lisp_machine

There's nothing inherently contradictory about running on bare metal, and being garbage collected. As long as you can manipulate memory directly, the garbage collector could potentially be implemented in the language itself. See the Boehm[1] GC as an example of a GC implemented in C for C/C++. [1]: https://www.hboehm.info/gc/ https://www.hboehm.info/gc/

deleted 5y ago
[deleted]
hootbootscoot 5y ago
that will need to bootstrap first, and you won't be able to use such GC code in the initialization code for the OS. GC code using Boehm would not be suitable for device drivers nor realtime code. I can understand where making it available for higher level systems is desirable. I could envision the kinds of alternative GC systems that could be inbuilt given the knowledge an OS may have about a process or a sub-system etc. Alternatively, Objective C settled upon reference counting (ARC) and this is superior to GC where it counts. Where do you envision the GC bootstrapping and how do you see it interacting with virtual memory and your malloc implementation?
- messe 5y ago
  > that will need to bootstrap first, and you won't be able to use such GC code in the initialization code for the OS. It's all highly dependent on the interface between the language and its runtime. Hypothetically, your C# runtime (and by runtime, I'm using it in the same sense that Rust or C++ would use it; I'm not referring to a VM) could provide a function that allocates memory (C#-esque pseudocode): public static ulong New(ulong bytes) { if (gcInitialized) { return GcNew(bytes); } else { return BootstrapHeapNew(bytes); } } Until the GC is boostrapped, all allocations are made on a heap, and either manually freed or kept around until the GC takes over deallocation. > GC code using Boehm would not be suitable for device drivers nor realtime code. I completely agree, I just provided it as an example of a GC implemented in the same language. > Where do you envision the GC bootstrapping and how do you see it interacting with virtual memory and your malloc implementation? I don't see the GC interacting with userland in this case, and instead would only be used for kernel data structures. I don't really think it's a good idea to have GC in a kernel, I only wanted to point out that low-level code and garbage collection are not mutually exclusive.
  - int_19h 5y ago
    For that matter, until you bootstrap GC+heap, you could just use statically allocated memory, or even local arrays (via stackalloc). This would preclude using any reference types, but you can do plenty of things with just structs and unmanaged function pointers alone in C# (it's basically the expressive equivalent of C, but with generics thrown in).
- pjmlp 5y ago
  > Alternatively, Objective C settled upon reference counting (ARC) and this is superior to GC where it counts. ARC does nothing special other than automate [myCocoaClass retain] and [myCocoaClass release], a compromise after putting a conservative trancing GC in Objective did not work as expected, given the amount of caveats with GC unaware C code. As such, Objective-C performance related to heap management remains unchanged.

pjmlp 5y ago

The kernel obviously. http://www.projectoberon.com/ http://www.projectoberon.com/

kryptiskt 5y ago

No, because there is no reason an OS couldn't have an integrated garbage collector. The garbage collector would have to be written in a non-garbage collected language or using a subset of the language that doesn't allocate on the GC heap, the no-runtime sample here shows that it would be possible to do one in C#. But there is no reason the rest of the OS couldn't use automatic memory management. Linux is a heavy user of refcounted data already, and there is no fundamental difference between that and other garbage collection strategies.

profquail 5y ago

Lisp machines had hardware/OS-based garbage collection ~40 years ago: https://en.m.wikipedia.org/wiki/Lisp_machine https://en.m.wikipedia.org/wiki/Lisp_machine