Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Garbage collection for Rust: The finalizer frontier

soft-dev.org

Post reply on HN
Print view View original

101–110 of 184 posts

Re: Garbage collection for Rust: The finalizer frontier

#101

Post by dajonker »

FridgeSeal wrote: post #100

I don’t understand the desire to staple a GC into Rust. If you want this, you might just…want a different language? Which is fine and good! Putting a GC on Rust feels like putting 4WD tyres on a Ferrari sports car and towing a caravan with it. You could (maybe) but it feels like using the wrong tool for the job.

If I understand the article correctly it's for those cases where you want memory safety (i.e. not using "unsafe") but where the borrow checker is really hard to work with such as a doubly linked list, where nodes can point to each other.

For the rest you'd still use non-GC rust.

Re: Garbage collection for Rust: The finalizer frontier

#102

Post by dajonker »

sebastianconcpt wrote: post #82

I'm curious about the applicability. If memory management is already resolved with the borrow checker rules, then what case can make you want a GC in a Rust program?

Implementing a doubly linked list without either unsafe or some very confusing code that could arguably win an obfuscation contest.

Re: Garbage collection for Rust: The finalizer frontier

#103

Post by grogers »

imtringued wrote: post #64
gwbas1c wrote: post #5

Before making criticisms that Garbage Collection "defeats the point" of Rust, it's important to consider that Rust has many other strengths: - Rust has no overhead from a "framework" - Rust programs start up quickly - The rust ecosystem makes it very easy to compile a command-line tool without lots of fluff - The strict nature of the language helps guide the programmer to write bug-free code. In short: There's a lot…

The problem with conventional garbage collection has very little to do with the principle or algorithms behind garbage collection and more to do with the fact that seemingly every implementation has decided to only support a single heap. The moment you can have isolated heaps almost every single problem associated with garbage collection fades away. The only thing that remains is that cleaning up memory as late as po…

BEAM (i.e. erlang) is exactly that model, every lightweight process has its own heap. I don't see how you'd make that work in a more general environment that supports sharing pointers across threads.

Re: Garbage collection for Rust: The finalizer frontier

#104

Post by FridgeSeal »

dajonker wrote: post #101
FridgeSeal wrote: post #100

I don’t understand the desire to staple a GC into Rust. If you want this, you might just…want a different language? Which is fine and good! Putting a GC on Rust feels like putting 4WD tyres on a Ferrari sports car and towing a caravan with it. You could (maybe) but it feels like using the wrong tool for the job.

If I understand the article correctly it's for those cases where you want memory safety (i.e. not using "unsafe") but where the borrow checker is really hard to work with such as a doubly linked list, where nodes can point to each other. For the rest you'd still use non-GC rust.

I just foresee it become irrevocably viral, as it becomes the “meh, easier” option, and then suddenly half your crates depend on it, and then you’re losing one of the major advantages of the language.

Re: Garbage collection for Rust: The finalizer frontier

#105

Post by nitwit005 »

IainIreland wrote: post #19
king_terry wrote: post #2

The whole point of Rust is to not have a garbage collector while not worrying about memory leaks, though.

One clear use case for GC in Rust is for implementing other languages (eg writing a JS engine). When people ask why SpiderMonkey hasn't been rewritten in Rust, one of the main technical blockers I generally bring up is that safe, ergonomic, performant GC in Rust still appears to be a major research project. ("It would be a whole lot of work" is another, less technical problem.) For a variety of reasons I don't think…

Once you are generating and running your own machine code, isn't the safety of Rust generally out the window?

Re: Garbage collection for Rust: The finalizer frontier

#106

Post by Rohansi »

astrange wrote: post #79
ltratt wrote: post #37

Earlier quoted context omitted.

If you've used Chrome or Safari to read this post, you've used a program that uses (at least in parts) conservative GC. [I don't know if Firefox uses conservative GC; it wouldn't surprise me if it does.] This partly reflects shortcomings in our current compilers and in current programming language design: even Rust has some decisions (e.g. pointers can be put in `usize`s) that make it hard to do what would seem at fi…

Also most mobile games written in C# use a conservative GC (Boehm).

Not just mobile games - all games made with Unity.

Re: Garbage collection for Rust: The finalizer frontier

#107

Post by MereInterest »

gwbas1c wrote: post #44

> Having acknowledged that pointers can be 'disguised' as integers, it is then inevitable that Alloy must be a conservative GC C# / dotnet don't have this issue. The few times I've needed a raw pointer to an object, first I had to pin it, and then I had to make sure that I kept a live reference to the object while native code had its pointer. This is "easier done than said" because most of the time it's passing strin…

Even their so-called conservative assumption is also insufficient.

> if a machine word's integer value, when considered as a pointer, falls within a GCed block of memory, then that block itself is considered reachable (and is transitively scanned). Since a conservative GC cannot know if a word is really a pointer, or is a random sequence of bits that happens to be the same as a valid pointer, this over-approximates the live set

Suppose I allocate two blocks of memory, convert their pointers to integers, then store the values `x` and `x^y`. At this point, no machine word points to the second allocation, and so the GC would consider the second allocation to be unreachable. However, the value `y` could be computed as `x ^ (x^y)`, converted back to a pointer, and accessed. Therefore, their reachability analysis would under-approximate the live set.

If pointers and integers can be freely converted to each other, then the GC would need to consider not just the integers that currently exist, but also every integer that could be produced from the integers that currently exist.

Re: Garbage collection for Rust: The finalizer frontier

#108

Post by tacticus »

guelo wrote: post #71
gizmo686 wrote: post #39

Earlier quoted context omitted.

Testing on my machine, Hello World in java (openjdk 21) takes about 30ms. In contrast, "time" reports that rust takes 1ms, which is the limit of it's precision. Python does Hello World in just 8ms, despite not having a separate AOT compilation step. The general guidance I've seen for interaction is that things start to feel laggy at 100ms; so 30ms isn't a dealbreaker, but throwing a third of your time budget at the b…

I'm trying and failing to imagine a situation where 30ms startup time would be a problem. Maybe some kind of network service that needs to execute a separate process on every request?

30ms is the absolute best case. Throw some spring in there and you're very quickly at 10s. rub some spring-soap and it's near enough to 60s

Re: Garbage collection for Rust: The finalizer frontier

#109

Post by zozbot234 »

dajonker wrote: post #101
FridgeSeal wrote: post #100

I don’t understand the desire to staple a GC into Rust. If you want this, you might just…want a different language? Which is fine and good! Putting a GC on Rust feels like putting 4WD tyres on a Ferrari sports car and towing a caravan with it. You could (maybe) but it feels like using the wrong tool for the job.

If I understand the article correctly it's for those cases where you want memory safety (i.e. not using "unsafe") but where the borrow checker is really hard to work with such as a doubly linked list, where nodes can point to each other. For the rest you'd still use non-GC rust.

A doubly linked list is not the optimal case for GC. It can be implemented with some unsafe code, and there are approaches that implement it safely with GhostCell (or similar facilities, e.g. QCell) plus some zero-overhead (mostly) "compile time reference counting" to cope with the invariants involved in having multiple references simultaneously "own" the data. See e.g. https://github.com/matthieu-m/ghost-collections for details.

Where GC becomes necessary is the case where even static analysis cannot really mitigate the issue of having multiple, possibly cyclical references to the same data. This is actually quite common in some problem domains, but it's not quite as simple as linked lists.

Re: Garbage collection for Rust: The finalizer frontier

#110

Post by marcianx »

worik wrote: post #67
vsgherzi wrote: post #63

No has seemed to call it out yet but swift uses a form of garbage collection but remains relatively fast. I was against this at first but the more I think about it, I think it has real potential to make lots of hard problems with ownership easier to solve. I think the next big step or perhaps an alternative would be to make changes to restrictions in unsafe rust. I think the pursuit of safety is a good goal and I cou…

Swift uses reference counting Slows down every access to objects as reference counts must be maintained Something weird that I never bothered with to enable circular references

Reference counted pointers can deference an object (via a strong pointer) without checking the reference count. The reference count is accessed only on operations like clone, destruction, and such. That being said, access via a weak pointer does require a reference count check.
Post reply on HN