They don't run GC, but they subject the extra pointers to GC, whereas good RC languages generally support values. Doing nothing is usually cheaper than doing something.

This is more a Java problem than a GC problem; C# supports values just fine, and some heroic JVM-targetting languages also manage it.

But then mark and sweep also doesn’t have to free the memory (it just does a bulk sweep occasionally), and RC languages do need to free memory used to hold the values later (they have to run expensive compaction and locking steps). So definitely more a Java problem with poor allocation hoisting and reuse than a difference between the RC and mark and sweep implementations of GC.

Rust isn't an "RC" language though like Java is a "GC" language. There's a lot of flexibility for how you handle allocations. It has actual unboxed/value structs; it has Box (heap allocation without reference counting); it has Rc (single-thread/no-atomic reference counting); it has Arc (atomic reference counting); it has epoch gc libraries. And, regarding this phrase:

> RC languages do need to free memory used to hold the values later

It also has arena allocators, so you can group allocations that will be freed at a similar time. You don't need to walk through these to find them all and individually free them. Anything with a Drop impl (destructor) gets thrown on a list for that to be taken care of; then the arena's relatively few, large blocks get freed all at once.

I've used this in C++ to squeeze the last bit of performance out of a high-request-rate server. I haven't done it in Rust, but it's the same idea.

btw, little confused by this:

> [RC languages?] have to run expensive compaction and locking steps

Was this meant to refer to GC languages? I've never seen one that does compaction (we're talking about the same thing? moving all the memory allocations around to reduce fragmentation?) That's more of a GC language thing that e.g. Java does; it would require the language/runtime to be able to precisely spot pointers and be able to throw in a trap when one it's changing is dereferenced or to entirely stop the world first.

Yes, rust is a great language. I love what it does. It also has memory leaks, because it is missing the cleanup part of the GC so it can’t deal with reference counter cycles.

Well, there is boehm if you do want to take on that complexity. But no, I am referring to the book keeping operations that are done internal to the malloc and free calls. They are largely hidden from you as the user of the API, but you still have to pay for them in runtime.

I thought rust didn’t have any safe arena allocators, but that some people make them by tricking the system with indexes instead and such, though word was they might come soon https://news.ycombinator.com/item?id=33403324

Are you interpreting "GC every heap allocation" as "each heap allocation causes an entire cycle of GC"? That's...not what that phrase means.

Yes I am. Java's GC can stop the world at any safepoint. It isn't limited to when objects are allocated and it doesn't do it every time.

I'm aware. A cycle per allocation would be absurdly expensive. "GC every heap allocation" actually means that every heap allocation is subject to garbage collection and has to be traversed on every cycle in which it's reachable. If the GC algorithm uses compaction and/or generations, it gets moved around too. That all has a cost.