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

141–150 of 184 posts

Re: Garbage collection for Rust: The finalizer frontier

#141

Post by Someone »

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

> Slows down every access to objects as reference counts must be maintained

Definitely not every access. Between an “increase refcount” and an “decrease refcount” you can access an object as many times as you want.

Also:

- static analysis can remove increase/decrease pairs.

- Swift structs are value types, and not reference counted. That means Swift code can have fewer reference-counted objects than similar Java code has garbage-collected objects.

It does perform slower than GC-ed languages or languages such as C and rust, but is easier to write [1] than rust and C and needs less memory than GC-ed languages.

[1] The latest Swift is a lot more complex than the original Swift, but high-level code still can be reasonably easy.

Re: Garbage collection for Rust: The finalizer frontier

#142

Post by Someone »

fulafel wrote: post #124
marcianx wrote: post #110

Earlier quoted context omitted.

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.

This sounds different from common refcounting semantics in other languages, is it really so in Swift? Usually access increases the reference count (to avoid the object getting GC'd while you use it) and weak pointers are the exception where you are prepared for the object reference to suddenly become invalid.

> Usually access increases the reference count

Taking shared ownership increases the reference count, not access.

Re: Garbage collection for Rust: The finalizer frontier

#143

Post by gudzpoz »

paulddraper wrote: post #136
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#.

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

... That post you linked was from two years ago, discussing JEP 295, which was delivered eight years ago. Graal-based AOT has evolved a lot ever since. And the answer even explicitly recommended using native images:

> I think what you actually want to do, is to compile a native image of your program. This would include all the implications like garbage collection from the JVM into the executable.

And it is this "native image" that all the comments above in this thread have been discussing, not JEP 295. (And Graal-based AOT in native images does remove the need to bundle a whole JRE.)

Re: Garbage collection for Rust: The finalizer frontier

#144

Post by ViewTrick1002 »

James_K wrote: post #35
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…

Go is probably a better pick in this case.

Inviting in nil errors, data races and a near non-existent type system.

Re: Garbage collection for Rust: The finalizer frontier

#145

Post by zozbot234 »

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…

You can pass a pointer to a foreign library, but this requires temporarily making the pointee object a GC root because that library code is essentially sharing ownership of it with the GC.

Re: Garbage collection for Rust: The finalizer frontier

#146

Post by lmm »

pjmlp wrote: post #140
lmm wrote: post #135

Earlier quoted context omitted.

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

"build tools" does not normally refer to those things.

Re: Garbage collection for Rust: The finalizer frontier

#147

Post by IshKebab »

tuveson wrote: post #20
jrop wrote: post #15

Earlier quoted context omitted.

Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.

Maybe try a different ML-influenced language like OCaml or Scala. The main innovation of Rust is bringing a nice ML-style type system to a more low level language.

I wouldn't recommend OCaml unless you plan to never support Windows. It finally does support it in OCaml 5 but it's still based around cygwin which totally sucks balls.

Also the OCaml community is miniscule compared to Rust. And the syntax is pretty bonkers in places, whereas Rust is mostly sane.

Compile time is pretty great though. And the IDE support is also pretty good.

Re: Garbage collection for Rust: The finalizer frontier

#148

Post by pjmlp »

lmm wrote: post #146
pjmlp wrote: post #140

Earlier quoted context omitted.

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

"build tools" does not normally refer to those things.

It does for me, using IDEs with Borland languages for MS-DOS.

It is about the whole package.

Re: Garbage collection for Rust: The finalizer frontier

#149

Post by IshKebab »

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.

You can get Rust binaries pretty small: https://github.com/johnthagen/min-sized-rust

But in practice it's more like there's an overhead for "hello world" but it's a fixed overhead. So it's really only a problem where you have lots of binaries, e.g. for coreutils. The solution there is a multi-call binary like Busybox that switches on argv[0].

C programs often seem small because you don't see the size of their dependencies directly, but they obviously still take up disk space. In some cases they can be shared but actually the amount of disk space this saves is not very big except for things like libc (which Rust dynamically links) and maybe big libraries like Qt, GTK, X11.

Re: Garbage collection for Rust: The finalizer frontier

#150

Post by IshKebab »

MereInterest wrote: post #107
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 t…

> If pointers and integers can be freely converted to each other

You can only freely convert integers to pointers with "exposed provenance" in Rust which is currently unstable.

https://doc.rust-lang.org/std/ptr/index.html#exposed-provena...

I find the idea of provenance a bit abstract so it's a lot easier to think about a concrete pointer system that has "real" provenance: CHERI. In CHERI all pointers are capabilities with a "valid" tag bit (it's out-of-band so you can't just set it to 1 arbitrarily). As soon as you start doing raw bit manipulation of the address the tag is cleared and then it can be no longer used as a pointer. So this problem doesn't exist on CHERI.

Also the problem of mistaking integers as pointers when scanning doesn't exist either - you can instead just search for memory where the tag bit is set.

Post reply on HN