3 ms·

> I think it's possible to write a kernel with GC, and to still be judicious about memory usage with a GC language. ... but I will still afford that it is techn

by gwbas1c 8mo ago

> I think it's possible to write a kernel with GC, and to still be judicious about memory usage with a GC language. ... but I will still afford that it is technically possible. I need to split some hairs for a bit: Do you mean what is colloquially referred to as "GC", as in the dotnet / Java / Javascript / golang "mark-and-sweep", fully-automatic style? Or do you mean other automatic memory management systems, which some people technically define as GC, like automatic reference counting? (IE, they clean up memory immediately, and except for requiring some manual form of breaking cyclic loops, generally are fully automatic?)

asveikau 8mo ago
Given that we are talking about JavaScript, I meant the former. The latter is pretty much the status quo in terms of the state of the art. Most kernels aren't built with automatic reference counting, reference counted objects are plentiful even if more manual, but the automatic part is trivial to add to a C++ code base using smart pointers for example, and things like rust or apple ARC can also do it. I think the former (a "true" GC that can resolve cycles) could be done in a kernel, it's just not common. I'm not well versed in this historical example, did the "lisp machine" not have a GC in its OS?
- gwbas1c 8mo ago
  According to https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine > These machines had hardware support for various primitive Lisp operations (data type testing, CDR coding) and also hardware support for incremental garbage collection. That being said, hardware garbage collection never really took off. When I look at GC languages they all have significantly different memory models, so I can see why. (For a more modern take on this, look into why dotnet can't use the proposed WASM garbage collector. Dotnet needs more metadata and finalizers, which WASM's GC doesn't provide.) But getting back to a Javascript kernel with GC: I would think "stop the world" pauses would cause non-deterministic issues? (IE, if an interrupt has a long pause due to a GC?) It might only work if the kernel borrowed techniques from "real time Java" programming techniques?

by gwbas1c 8mo ago

asveikau 8mo ago

Given that we are talking about JavaScript, I meant the former. The latter is pretty much the status quo in terms of the state of the art. Most kernels aren't built with automatic reference counting, reference counted objects are plentiful even if more manual, but the automatic part is trivial to add to a C++ code base using smart pointers for example, and things like rust or apple ARC can also do it. I think the former (a "true" GC that can resolve cycles) could be done in a kernel, it's just not common. I'm not well versed in this historical example, did the "lisp machine" not have a GC in its OS?

gwbas1c 8mo ago
According to https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine > These machines had hardware support for various primitive Lisp operations (data type testing, CDR coding) and also hardware support for incremental garbage collection. That being said, hardware garbage collection never really took off. When I look at GC languages they all have significantly different memory models, so I can see why. (For a more modern take on this, look into why dotnet can't use the proposed WASM garbage collector. Dotnet needs more metadata and finalizers, which WASM's GC doesn't provide.) But getting back to a Javascript kernel with GC: I would think "stop the world" pauses would cause non-deterministic issues? (IE, if an interrupt has a long pause due to a GC?) It might only work if the kernel borrowed techniques from "real time Java" programming techniques?