Hacker News Reader

Comment by MatthiasPortzel | Hacker News Reader

I’m not a Rust programmer, but I’ve heard Rust has compile-time AST macros. I wonder if it would be possible to implement a Rust GC by defining a macro to tag garbage collected sections of code. The macro expansion could then insert cycle-checks on moves as described early in the post. I have no intuition for how performance would compare to the trait-based approach that the author went with.

View on HN

IME a lot of people want some kind of help from the compiler when writing a GC, but there is the fundamental static vs. dynamic problem.

Heap integrity / reachability is a dynamic property of a running program, and so all the static solutions basically end up as half-measures. (I imagine this would include using macros, though I don't know exactly what you mean),

FWIW this is my experience - https://www.oilshell.org/blog/2023/01/garbage-collector.html

Take it with however many grains of salt, but I heard many static solutions proposed, and they're all "wrong" for the simple reasons in theory of computation.

Also, Rust's static memory management inherently clashes a bit with dynamic memory management. That's also a fundamental thing, and you can have a bazillion mechanisms to ameloriate it for some cases (which may be valuable), but the problem will still be there no matter what.

In Rust, macros work at the tokenization level. Making a macro do that would require the macro to fully parse and analyze the syntax tree - possible, but not very efficient. Additionally, there's no guardrail to enforce that the user doesn't move a `Gc` anyway.

Yeap. 2 flavors: procedural and pattern matching. Even the build can be scripted in Rust. And there is constant evaluation. https://doc.rust-lang.org/reference/const_eval.html

Rust already has precise heap allocations with Box and Rc/Arc without the need for GC. GC implies uncomputed heap allocation liveness deferring work until later.

Rc is reference counting, which is garbage collection, although not tracing garbage collection. Though optimizing RC throughput tends to involve deferral (and optimising tracing latency tends to involve more upfront work on the mutator) <https://web.eecs.umich.edu/~weimerw/2012-4610/reading/bacon-...>

Rc/Arc in rust are precise and immediate. There is no garbage to collect later. I wouldn't call that GC, it's functionality of a heap one level up from malloc/sbrk.

That's still a fine GC. Although ridiculous, consider performing a tracing GC after every assignment - that system would provide the same immediacy (or better, due to cycle detection).

Reply on news.ycombinator.com