Garbage collection for Rust: The finalizer frontier • Hacker News Board

Re: Garbage collection for Rust: The finalizer frontier

#91

Post by haberman » Wed, Oct 15, 2025, 9:03 PM UTC

taylorallred wrote: post #21

For those who are interested, I think that arena allocation is an underrated approach to managing lifetimes of interconnected objects that works well with borrow checking.

I agree, but in my experience arena allocation in Rust leaves something to be desired. I wrote something about this here: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html

I was previously excited about this project which proposed to support arena allocation in the language in a more fundamental way: https://www.sophiajt.com/search-for-easier-safe-systems-prog...

That effort was focused primarily on learnability and teachability, but it seems like more fundamental arena support could help even for experienced devs if it made patterns like linked lists fundamentally easier to work with.

Re: Garbage collection for Rust: The finalizer frontier

#92

Post by pjmlp » Wed, Oct 15, 2025, 9:03 PM UTC

kbolino wrote: post #32

procaryote wrote: post #25

Earlier quoted context omitted.

Hello world in java is pretty fast. Not rust fast but a lot faster than you'd expect. Java starting slowly is mostly from all the cruft in the typical java app, with springboot, dependency injection frameworks, registries etc. You don't have to have those, it's just that most java devs use them and can't conceive of a world of low dependencies Still not great for commandline apps, but java itself is much better than…

Java's biggest weakness in this area is its lack of value types. It's well known, Project Valhalla has been trying to fix it for years, but the JVM just wasn't built around such types and it's hard to bolt them on after the fact. Java's next biggest weakness (which will become more evident with value types) is its type-erased generics. Both of these problems lead to time wasted on unnecessary GC, and though they can…

Currently it takes lots of boilerplate code, however with Project Panama API you can model C types in memory, thus kind of already using value types even if Valhala isn't yet here.

To avoid manually writing all the Panama boilerplate, you can instead write a C header file with the desired types, and then run jextract through it.

Re: Garbage collection for Rust: The finalizer frontier

#93

Post by pjmlp » Wed, Oct 15, 2025, 9:05 PM UTC

tayo42 wrote: post #40

procaryote wrote: post #28

Earlier quoted context omitted.

it depends completely on what you put in "modern features"

Pattern matching, usable abstractions, non null types, tagged unions or w/e enums are, build tools etc

Standard ML from 1983, alongside all those influenced by it like Haskell, OCaml, Agda, Rocq,....

Re: Garbage collection for Rust: The finalizer frontier

#94

Post by celeritascelery » Wed, Oct 15, 2025, 9:09 PM UTC

GolDDranks wrote: post #65

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…

Also, Rust is not going to have it for the long run that pointers can be, in fact, disguised as integers. There is this thing called pointer provenance, and some day, all pointers are required to have provenance (i.e. a proof where they did come from) OR they are required to admit that POOF this is a pointer out of thin air, you can't assume anything about the pointee. As long as there are no POOF magicians, the GC c…

> As long as there are no POOF magicians, the GC can assume that it knows every reference!

creating pointers without provenance is safe, so the GC can’t assume that a program won’t have them also be sound. This always be an issue.

Re: Garbage collection for Rust: The finalizer frontier

#95

Post by quotemstr » Wed, Oct 15, 2025, 9:18 PM UTC

ltratt wrote: post #62

quotemstr wrote: post #60

Earlier quoted context omitted.

It's not an implementation thing. It's fundamental. A GC can't move anything it finds in a conservative root. You can build partly precise hybrid GCs (I've built a few) but the mere possibility of conservative roots complicates implementation and limits compaction potential. If, OTOH, Alloy is handle based, then maybe there's hope. Still a weird choice to use Rust this way.

We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice. I don't think Rust's design in this regard is ideal, but then again what language is perfec…

> We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice.

You can define a set of objects for which this transformation is illegal --- use something like pin projection to enforce it.

Re: Garbage collection for Rust: The finalizer frontier

#96

Post by Archit3ch » Wed, Oct 15, 2025, 9:24 PM UTC

celeritascelery wrote: post #85

worik wrote: post #72

Earlier quoted context omitted.

> works well with borrow checking. Yes, because it defeats borrow checking. Unsafe Rust, used directly, works too

It does not defeat borrow checking. The borrow checker will ensure that objects do not outlive the arena. It works with borrow checking.

This. Arenas don't work when you don't know when it's okay to free. The borrow checker can help with that (or you can track it manually in C/Zig).

Re: Garbage collection for Rust: The finalizer frontier

#97

Post by ltratt » Wed, Oct 15, 2025, 9:27 PM UTC

quotemstr wrote: post #95

ltratt wrote: post #62

Earlier quoted context omitted.

We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice. I don't think Rust's design in this regard is ideal, but then again what language is perfec…

> We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice. You can define a set of objects for which this transformation is illegal --- use somethin…

The only way to forbid it would be to forbid creating pointers from `Gc`. That would, for example, preclude a slew of tricks that high performance language VMs need. That's an acceptable trade-off for some, of course, but not all.

Re: Garbage collection for Rust: The finalizer frontier

#98

Post by jraph » Wed, Oct 15, 2025, 9:30 PM UTC

pjmlp wrote: post #88

gwbas1c wrote: post #13

Earlier quoted context omitted.

Oh no, I'm directly criticizing C/C++/Java/C#: The heavyweight framework (and startup cost) that comes with Java and C# makes them challenging for widely-adopted lightweight command-line tools. (Although I love C# as a language, I find the Rust toolchain much simpler and easier to work with than modern dotnet.) Building C (and C++) is often a nightmare.

Only for those that don't know how to use AOT compilation tools for Java and C#.

GraalVM indeed do wonders wrt startup times and in providing a single binary you can call.

Re: Garbage collection for Rust: The finalizer frontier

#99

Post by quotemstr » Wed, Oct 15, 2025, 9:33 PM UTC

ltratt wrote: post #97

quotemstr wrote: post #95

Earlier quoted context omitted.

> We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice. You can define a set of objects for which this transformation is illegal --- use somethin…

The only way to forbid it would be to forbid creating pointers from `Gc `. That would, for example, preclude a slew of tricks that high performance language VMs need. That's an acceptable trade-off for some, of course, but not all.

Not necessarily. It would just require that deriving these pointers be done using an explicit lease that would temporarily defer GC or lock an object in place during one. You'd still be able to escape from the tyranny of conservative scanning everything.

Re: Garbage collection for Rust: The finalizer frontier

#100

Post by FridgeSeal » Wed, Oct 15, 2025, 9:39 PM UTC

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.