Maybe crazy idea but couldn't you implement a kernel level garbage collector for compiled languages like C/C++/Rust?

The biggest issue is that without a runtime you don't have safe points at which you know a thread isn't updating references... except you do! At thread context switches you know the thread isn't executing code, so you can safely do your stack traversal and reference marking without fearing race conditions

That's still somewhat problematic because OTHER threads may still be executing but there's probably concurrent gc designs that could deal with that...

Hmm maybe I should actually try to work on this

@chatgpt what about kernel-level garbage collectors for memory-unsafe languages? Are there/have there been any attempts to implement them? If yes - have any examples? Did they work and why aren't they mainstream? If not - why not? Not feasible [if so - why?]? Noone's had this idea before? Any other reasons?

Feel free to elaborate, share references if applicable

@netikras
Kernel-level garbage collectors for memory-unsafe languages have been explored and implemented in various research projects over the years. One notable example is the Singularity operating system developed by Microsoft Research, which utilized a kernel-level garbage collector to ensure memory safety in systems programming languages like C#.

While such attempts have shown promise in providing memory safety in low-level languages, they have not gained widespread adoption for a few reasons. One reason is the performance overhead associated with kernel-level garbage collection, as it introduces additional complexity and potential bottlenecks in the system. This overhead might make it less attractive to use in performance-critical applications where speed is paramount.

Additionally, incorporating kernel-level garbage collection requires significant changes to existing operating systems and runtime environments, which can be a challenging and time-consuming process. As a result,

many developers and organizations may opt for other solutions, such as language-level garbage collectors or manual memory management techniques.

Overall, while the concept of kernel-level garbage collectors for memory-unsafe languages has been explored, their feasibility and practicality in real-world applications remain a topic of ongoing research and debate. More research and development are needed to address the technical challenges and limitations associated with implementing and scaling such systems.

@chatgpt are there any Linux kernel-level garbage collectors for mem-unsafe languages out there? Perhaps as an optional kernel module rather than a separate distro, to easily enable/disable it where [not] needed? Elaborate pls

@netikras
There are no specific Linux kernel-level garbage collectors designed for mem-unsafe languages such as C or C++ that operate at the kernel level. Garbage collection is typically handled at the application level in these languages through runtime libraries or custom memory management strategies.

However, there have been some research efforts to explore the possibility of integrating garbage collection mechanisms into the operating system kernel itself. These projects aim to improve memory management and safety for applications written in programming languages like C and C++ that do not have built-in garbage collection.

One notable project in this space is Raven, which is a research operating system that provides kernel-level garbage collection for C and C++ applications. Raven aims to automatically release memory that is no longer in use, reducing the risk of memory leaks and buffer overflows.

Another approach is to use tools like AddressSanitizer or Valgrind, which can help

detect memory bugs in C and C++ code at runtime. While not technically garbage collectors, these tools can help identify memory errors and leaks, improving the reliability and security of applications.

In conclusion, while there are ongoing research efforts to explore kernel-level garbage collection for mem-unsafe languages, there are currently no widely adopted solutions available as a kernel module in Linux. Developers looking to improve memory safety in their applications may consider using existing tools and techniques to detect and prevent memory issues.

Not sure if kernel level but there is C++/CLI

I did this whole project without one leak until Python support was implemented https://molodetz.nl/retoor/pgs.

Yes, I know I didn't unset the SysPatch variable. I'm in middle of a refactor.

But thing is, I think many c programmers aren't interested in a safer language. At a certain moment trough suffering you've learned and even started to appreciate it. For many devs it's just not an issue. What memory issues do you experience daily?

@Lensflare ooh, Ive heard about this

I believe they're running c++ inside the CLR vm though

@retoor It's not about safety for me (I'm using Rust after all), it's more that it's just nice to not have to think about reference cycles in gamdev. I want reference spaghetti and i want it now!

This is my honest experience. There are a lot of untrue recommendations but because i haven't worked with all of them i can't tell you not to trust all of them. I won't be the one to alter someone's livelihood. If you have lost money to scam anytime at all, there is a solution. Send a mail to this recovery team ( contactzattechrecovery @ GMAIL COM ) to get the peace of mind you deserve.