pebal

Provide the GC name.

Every GC in Java involves synchronization points and the pausing of application threads.

It’s great that they were created for this purpose, but I have a faster allocator in non-moving GC engine in C++. And I don't have to moving gigabytes of data.

A moving GC does not provide the fastest allocation. This is one of the myths in the Java world.

ZGC is not pause-free. The only pause-free GC that exists is SGCL for the C++.

Rust could just as well have an optional tracing GC for shared ownership instead of ARC, potentially improving performance rather than reducing it. Having a GC doesn't inherently make a language slower.

I’m not saying it doesn't work. I’m saying it’s a waste of resources and won’t gain widespread popularity. The current trend is porting source code to languages that generate native code.

It depends on the workload. ARC can be more expensive than tracing GC, especially with heavily shared objects.

But my main point was that the presence of a GC has nothing to do with how close a language is to the metal. Memory management strategy and low-level capabilities are two separate things.

WASM makes no sense and has no future.

An absurd amount. The cost wouldn't exceed $500 under a subscription model.

There is no connection. Rust has ARC which performs worse than the tracing GC.

What exactly don't you understand?

Manual management involves an explicit function call. Functions called by a destructor are considered automatic.

Yes, I can, e.g. by implementing deferred deallocation, which is a primitive GC form.

> actually, you don't know

I know because I’ve verified it.

You might lose 100 ns or 300 ms. When? Nobody knows. You lose nothing when going out of scope with GC.

It is also unknown how much work will be performed if ARC goes out of scope.

Because some people are allergic to the word GC and pretend that a duck isn't a bird.

That "good collector" has higher memory usage, has to pause mutator threads, and makes application code run slower. Thanks, but no thanks.

It is better to scan everything than to copy it.

> The problem with GC in the strict sense is that you cannot predict when it will happen.

It’s the same with ARC. You also don’t know when the counter will reach zero.

The inefficient combination of reference counting and a tracing garbage collector found in Python should be discarded in favor of a fully pause-free, concurrent GC.

The standard provided no GC support. What was there was completely useless.

RC is a GC method and the least efficient one.

The C++ standard has never included a garbage collector. It only provided mechanisms intended to facilitate the implementation of a GC, but they were useless.

This isn't fully concurrent GC. It pauses mutators threads and delegates them to perform some of the work for the GC.

> I haven't seen a C++ programmer carefully opt into GC for a subset of their allocations even though there are GC libraries written for the language.

Can you give an example of such GC libraries?

> Whoever made that claim? Gamedevs particulary have been writing custom memory allocators since decades precisely because they know free() is not free and malloc() isn't fast.

Game developers use engines based on the GC.

> It's not an illusion, you literally use control over memory management.

The shared_ptr does not provide full control.

> What they don't want is random stalls in odd frames.

You can have fully concurrent GC, without any stalls.

But that's why Swift generates slower code. Memory is cheap, also for Apple, although Apple would like to hide that fact.

It doesn't matter at all. C4 uses STW.

Azul C4 is not a pauseless GC. In the documentation it says "C4 uses a 4-stage concurrent execution mechanism that eliminates almost all stop-the-world pauses."

There are no production implementations of GC algorithms that don't stop the world at all. I know this because I have some expertise in GC algorithms.