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

131–140 of 184 posts

Re: Garbage collection for Rust: The finalizer frontier

#131

Post by quotemstr »

gwbas1c wrote: post #81
quotemstr wrote: post #47

Earlier quoted context omitted.

Worse, conservatism in a GC further implies it can't be a moving GC, which means you can't compact, use bump pointer allocation, and so on. It keeps you permanently behind the frontier. I remain bitterly disappointed that so much of the industry is so ignorant of the advances of the past 20 years. It's like it's 1950 and people are still debating whether their cloth and wood airplanes should be biplanes or triplanes.

The thing I don't understand is why anyone would pass a pointer to a GC'ed object into a 3rd party library (that's in a different language) and expect the GC to track the pointer there? Passing memory into code that uses a different memory manager is always a case where automatic memory management shouldn't be used. IE, when I'm using a 3rd party library in a different language, I don't expect it to know enough about…

> The thing I don't understand is why anyone would pass a pointer to a GC'ed object into a 3rd party library

The promise of GC is to free the programmer from the burden of memory management. If I can't give (perhaps fractional) ownership of a data structure to a library and expect its memory to be reclaimed at the appropriate time, have I freed myself from the burden of memory management?

Re: Garbage collection for Rust: The finalizer frontier

#132

Post by pjmlp »

lmm wrote: post #116
pjmlp wrote: post #93

Earlier quoted context omitted.

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

Most of those have nothing remotely approaching Rust's level of build tooling.

Yet parent was mostly talking about type systems.

If you prefer, Rust tooling is still quite far behind from languages like Kotlin and Scala, which I didn't mention, but also have such type system.

Re: Garbage collection for Rust: The finalizer frontier

#133

Post by pjmlp »

jraph wrote: post #98
pjmlp wrote: post #88

Earlier quoted context omitted.

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.

Open J9 as well.

Then there are all the others that used to be commercial like ExcelsiorJET, or surviving ones like PTC and Aicas.

Re: Garbage collection for Rust: The finalizer frontier

#134

Post by Manishearth »

zorgmonkey wrote: post #59
Manishearth wrote: post #34

Earlier quoted context omitted.

Worth highlighting: library-level GC would not be convenient enough to use pervasively in Rust anyway . library-level GC does not replace Rust's "point". It's useful to have when you have complex graph structures. Or when implementing language runtimes. I've written a bit about these types of use cases in https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe... And there's a huge benefit in being able to narro…

This is a very important point, careful use of GCs for a special subset of allocations that say have tricky lifetimes for some reason and aren't performance critical could have a much smaller impact on overall application performance than people might otherwise expect.

Yeah, and it's even better if you have a GC where you can control when the collection phase happens.

E.g. in a game you can force collection to run between frames, potentially even picking which frames it runs on based on how much time you have. I don't know if that's a good strategy, but it's an example of the type of thing you can do.

Re: Garbage collection for Rust: The finalizer frontier

#135

Post by lmm »

pjmlp wrote: post #132
lmm wrote: post #116

Earlier quoted context omitted.

Most of those have nothing remotely approaching Rust's level of build tooling.

Yet parent was mostly talking about type systems. If you prefer, Rust tooling is still quite far behind from languages like Kotlin and Scala, which I didn't mention, but also have such type system.

> If you prefer, Rust tooling is still quite far behind from languages like Kotlin and Scala

I'm not sure that's true, at least when it comes to specifically build tooling. I'd say Cargo is far ahead of Gradle, Ant, or worst of all SBT, and probably even slightly ahead of Maven (which never really reached critical mass in the Kotlin or Scala ecosystems sadly).

Re: Garbage collection for Rust: The finalizer frontier

#136

Post by paulddraper »

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#.

Compiling Java AOT doesn’t obviate the need for the JVM.

At least not for Graal.

https://stackoverflow.com/questions/75316542/why-do-i-need-j...

Re: Garbage collection for Rust: The finalizer frontier

#137

Post by paulddraper »

drnick1 wrote: post #122
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…

Aren't Rust programs still considerably larger than their C equivalent because everything is statically linked? It's kind of hard to see that as an advantage.

No.

They may be larger because they are doing more work, depends on the program.

But no they don’t statically compile everything.

Re: Garbage collection for Rust: The finalizer frontier

#138

Post by typpilol »

0cf8612b2e1e wrote: post #66
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 recall that Mercurial was really fighting their Python test harness. It essentially would startup a new Python process for each test. At 10ms per, it added up to something significant, given their volume of work to cover something as complicated as SCM.

10ms?

Did they have like 100k tests?

Re: Garbage collection for Rust: The finalizer frontier

#139

Post by paulddraper »

tuveson wrote: post #80
imtringued wrote: post #64

Earlier quoted context omitted.

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…

What problem does that solve with GC, specifically? It also seems like that creates an obvious new problem: If you have multiple heaps, how do you deal with an object in heap A pointing to an object in heap B? What about cyclic dependencies between the two? If you ban doing that, then you’re basically back to manual memory management.

There’s a ton of work that goes into multi-generational management, incremental vs stop the world, frequency heuristics, etc.

A lot of the challenge is there is not just one universal answer for these, the optimum strategies vary case by case.

You are correct that each memory arena is the boundary of the GC. Any GC between them must be handled manually.

Re: Garbage collection for Rust: The finalizer frontier

#140

Post by pjmlp »

lmm wrote: post #135
pjmlp wrote: post #132

Earlier quoted context omitted.

Yet parent was mostly talking about type systems. If you prefer, Rust tooling is still quite far behind from languages like Kotlin and Scala, which I didn't mention, but also have such type system.

> If you prefer, Rust tooling is still quite far behind from languages like Kotlin and Scala I'm not sure that's true, at least when it comes to specifically build tooling. I'd say Cargo is far ahead of Gradle, Ant, or worst of all SBT, and probably even slightly ahead of Maven (which never really reached critical mass in the Kotlin or Scala ecosystems sadly).

You are missing the IDE capabilities, maturity of GUI frameworks, a full OS that 80% of the world uses,... the whole tooling package.
Post reply on HN